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.
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: