Skip to content

docs: state behavior for url pathname and percent encoding #1538

Closed
@gopat

Description

@gopat

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 IncomingMessages (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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    docIssues and PRs related to the documentations.good first issueIssues that are suitable for first-time contributors.urlIssues and PRs related to the legacy built-in url module.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions