-
Notifications
You must be signed in to change notification settings - Fork 572
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Relax parseOrigin validation to allow paths withe "/" #4000
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for opening a PR! Can you please add a unit test?
Hi @mcollina, I've added unit tests for the parseOrigin function to validate the changes. The tests confirm URLs with paths are now accepted while invalid cases are still rejected. Let me know if further adjustments are needed. 😊 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does it impact undici.request()
and other methods? Can y
const validSimpleUrl = 'https://api.domain.com' | ||
const simpleResult = parseOrigin(validSimpleUrl) | ||
assert.strictEqual(simpleResult.href, `${validSimpleUrl}/`, 'Should return the input URL with the trailing slash') | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does it impact undici.request()
and other methods? Can you add a test for that?
This relates to...
#3999
This pull request resolves an issue with overly restrictive URL validation in the
parseOrigin
function incore/util.js
. Specifically, the function was rejecting valid URLs with paths.Rationale
The previous implementation of
parseOrigin
rejected URLs with paths, such ashttps://api.domain.com/elastic
, even though such URLs are valid in many use cases. By relaxing the condition on thepathname
check, the function now allows URLs with paths, while still maintaining validation for query strings (search
) and fragments (hash
).This change makes the library more flexible and usable in real-world scenarios where Elasticsearch and other similar services often use paths in their base URLs.
Changes
parseOrigin
function incore/util.js
to relax the validation logic forpathname
.Features
N/A – this is not a new feature but a bug fix.
Bug Fixes
parseOrigin
function, allowing URLs with paths.Breaking Changes and Deprecations
The modified validation does not affect existing use cases where paths were not used in URLs. It only adds support for previously invalid cases.
Status