Trailing slash causes different behavior in Path.resolve and Url.resolve

[ivan-kleshnin]

import Url from "url";
import Path from "path";

// Example 1 ==================
let dir = "/uploads/foo/"; // trailing slash
let filename = "bar.jpg";

Url.resolve(dir, filename);  // "/uploads/foo/bar.jpg"
Path.resolve(dir, filename); // "/uploads/foo/bar.jpg "
// Url.resolve <=> Path.resolve

// Example 2 ===================
let dir = "/uploads/foo"; // no trailing slash
let filename = "bar.jpg";

Url.resolve(dir, filename);  // "/uploads/bar.jpg"
Path.resolve(dir, filename); // "/uploads/foo/bar.jpg"
// // Url.resolve <!=> Path.resolve

I expected from Url.resolve and Path.resolve to return the same result with that inputs.
Trailing slash is a weak condition to depend IMO.

Node v4.2.2
OS X 10.9.5

[Trott]

The reason url.resolve() works the way it does with trailing slashes is explained indirectly in the docs for url.resolve():

Take a base URL, and a href URL, and resolve them as a browser would for an anchor tag.

That would make no sense for path.resolve() but makes sense for url.resolve().

[cjihrig]

path is also just string manipulation. Without depending on the trailing slash, there isn't a good way to differentiate between a file and a directory.

[Fishrock123]

Keep in mind they are not identical; one is for URLs and one is for filesystems. :)

[ivan-kleshnin]

@cjihrig than how that difference between "directory" and "file" is not actual for path module?
For me it seems fairly logical to unify both behaviors in either first or second way.
Clunky and unobvious rules for such simple things are exact reasons why people
still use concatenation for paths.

Keep in mind they are not identical; one is for URLs and one is for filesystems. :)

Very sharp.

[pronebird]

I seriously had a WTF moment today and this is exactly the problem. It's the same problem with the new URL class and it's exactly why I'd rather use url-join because we've got base URLs coming from env and hell is gonna break lose if someones misses that trailing slash.

I have no idea why it's designed that way and who thought it's a good idea to do heuristics on files and folders in URLs, especially in base URLs.

new URL('zomg/omg.png', 'https://cloudfront.com/test')
URL {
  href: 'https://cloudfront.com/zomg/omg.png',
  origin: 'https://cloudfront.com',
  protocol: 'https:',
  username: '',
  password: '',
  host: 'cloudfront.com',
  hostname: 'cloudfront.com',
  port: '',
  pathname: '/zomg/omg.png',
  search: '',
  searchParams: URLSearchParams {},
  hash: '' }

[Trott]

I have no idea why it's designed that way and who thought it's a good idea to do heuristics on files and folders in URLs, especially in base URLs.

It's not really heuristics. It's the spec-designated algorithm. Here is an example given in a table in the spec: If the URL provided is example and the base URL is https://example.com/demo, then the resulting URL is https://example.com/example.

[pronebird]

@Trott This is very impractical. Consider the following example when working with path:

$ node
> var path = require('path')
> path.join('/abc/d', 'fg')
'/abc/d/fg'
> path.resolve('/abc/d', 'fg')
'/abc/d/fg'
> path.resolve('/abc/d/', 'fg')
'/abc/d/fg'
> path.resolve('/abc/d', '../fg')
'/abc/fg'
> path.resolve('/abc/d/', '../fg')
'/abc/fg'

The path module is consistent. Either the WhatWG lacks some abstractions around URL paths, or it's a badly designed spec.

I just can't believe that we keep reinventing such fundamental things in 2019.

[kishmiryan-karlen]

It's not really heuristics. It's the spec-designated algorithm. Here is an example given in a table in the spec: If the URL provided is example and the base URL is https://example.com/demo, then the resulting URL is https://example.com/example.

I just came across to this thread while having a bit different issue and @Trott, it seems what you are saying is not so true or the url package is not up-to-date with the latest spec you referred.

To highlight the mismatch between the package and spec, you can checkout this example: https://url.spec.whatwg.org/#example-url-components, which says, that after parsing the https://example.com/, the URL instance should have "path" as "empty string", whereas the package parses it as path: "/" (see example1 in screenshot). I'm ok with this and I think the spec is not right regarding this part.

However, there's still an issue in package, because it also sets the path: "/" even when there's no trailing slash (see example2 in screenshot).

In my case, I'm receiving a URL string, which might have a trailing slash or not. I have to add query params on it and tried to do it using URL class. However, when creating a new instance of URL, it parses the the URL string in the same way regardless it has a trailing slash or not. So, after parsing and adding search params, the "href" property will always be like: http://example.com/?id=1, which can cause issues if that host doesn't support trailing slash.

[Trott]

To highlight the mismatch between the package and spec, you can checkout this example: https://url.spec.whatwg.org/#example-url-components, which says, that after parsing the https://example.com/, the URL instance should have "path" as "empty string", whereas the package parses it as path: "/" (see example1 in screenshot). I'm ok with this and I think the spec is not right regarding this part.

I believe you are misunderstanding that table and the spec. path is not anything that is included in URL. pathname is included in URL based on path. path is a list. In that table, it is a list containing a single entry: An empty string.

The algorithm for the getter for pathname elsewhere in the spec indicates that this will be represented as '/'.

You can confirm this by seeing that browsers have the same behavior.