Description
Shouldn't be stated in the docs that url module does NOT touch pathname
or pathname part of path
(no percent encoding/decoding) when extracting-from/putting-into urls?
> url.parse('https://example.com/pathname%20with%20fun%20incorporated%3d/?adf=f4&er4=%40',false);
{ protocol: 'https:',
slashes: true,
auth: null,
host: 'example.com',
port: null,
hostname: 'example.com',
hash: null,
search: '?adf=f4&er4=%40',
query: 'adf=f4&er4=%40',
pathname: '/pathname%20with%20fun%20incorporated%3d/',
path: '/pathname%20with%20fun%20incorporated%3d/?adf=f4&er4=%40',
href: 'https://example.com/pathname%20with%20fun%20incorporated%3d/?adf=f4&er4=%40' }
> url.parse('https://example.com/pathname%20with%20fun%20incorporated%3d/?adf=f4&er4=%40',true);
{ protocol: 'https:',
slashes: true,
auth: null,
host: 'example.com',
port: null,
hostname: 'example.com',
hash: null,
search: '?adf=f4&er4=%40',
query: { adf: 'f4', er4: '@' },
pathname: '/pathname%20with%20fun%20incorporated%3d/',
path: '/pathname%20with%20fun%20incorporated?adf=f4&er4=%40',
href: 'https://example.com/pathname%20with%20fun%20incorporated?adf=f4&er4=%40' }
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 in path
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 in IncomingMessage
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.