-
Notifications
You must be signed in to change notification settings - Fork 29.4k
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
docs: state behavior for url pathname and percent encoding #1538
Labels
doc
Issues and PRs related to the documentations.
good first issue
Issues that are suitable for first-time contributors.
url
Issues and PRs related to the legacy built-in url module.
Comments
mscdex
added
doc
Issues and PRs related to the documentations.
url
Issues and PRs related to the legacy built-in url module.
labels
Apr 27, 2015
Fishrock123
added
the
good first issue
Issues that are suitable for first-time contributors.
label
Apr 28, 2015
Fishrock123
changed the title
API Documentation: url module, state behavior with respect to pathname and percent encoding
docs: state behavior for url pathname and percent encoding
Apr 28, 2015
silverwind
pushed a commit
that referenced
this issue
May 25, 2015
Explicitly states the fact that no decoding is performed on the url path or pathname or the query string by default in the URL module. Fixes: #1538 PR-URL: #1731 Reviewed-By: Roman Reiss <[email protected]>
Fixed by a74c2c9 |
andrewdeandrade
pushed a commit
to andrewdeandrade/node
that referenced
this issue
Jun 3, 2015
Explicitly states the fact that no decoding is performed on the url path or pathname or the query string by default in the URL module. Fixes: nodejs/node#1538 PR-URL: nodejs/node#1731 Reviewed-By: Roman Reiss <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
doc
Issues and PRs related to the documentations.
good first issue
Issues that are suitable for first-time contributors.
url
Issues and PRs related to the legacy built-in url module.
Shouldn't be stated in the docs that url module does NOT touch
pathname
or pathname part ofpath
(no percent encoding/decoding) when extracting-from/putting-into urls?In fact, it does not do any percent encoding/decoding at all in query/search -with the exception of opt-in querystring parsing (
parseQueryString
argument) or when encoding an object including query params to a full url-.In this case (querystring/search whatever you call it) it is pretty obvious (decoding without parsing leads to incorrect data, ie:
'?a=%26b'
), and it is kind of implicitly documented in the examples, though.But stating it clearly in the docs for
pathname
and pathname part inpath
should let api users avoid the 'implemetation' vs 'intended' behavior dilemma: trusty, future-proof('till api change) behavior.I'm ssuming that it is intended behavior. If it happens to be an implementation detail... i'm not related to the project but if asked would be +1 on current behavior: raw original data available, that can be decoded if needed, so we don't lose upper/lowercase info for percent escapes (of significance to oauth1.0a).
Notes: http module:
url
property inIncomingMessage
s (http.Server
'request' event) is consistent with url module behavior right now. "Fix" docs too ?PD: My humble apologies for the poor quality of my mind's English implementation.
The text was updated successfully, but these errors were encountered: