Removing trailing C0 control or space at basic URL parser makes difference with override

[watilde]

Steps to reproduce

The below console.log should show the same result. Otherwise: #542 (comment)

const hash = 'test\x00';
const url = new URL(`http://a.com/#${hash}`)

console.log(url.href)
// => http://a.com/#test

url.hash = hash
console.log(url.href)
// => http://a.com/#test%00

Summary

Because the basic URL parser removes trailing c0 control or space only when url is not given, it makes a difference with override.

Refs: https://url.spec.whatwg.org/#url-parsing

1. If url is not given:
  1.Set url to a new URL.
  2. If input contains any leading or trailing C0 control or space, validation error.
  3. Remove any leading and **trailing C0 control or space** from input.

Potential solutions would be below two:

1. Opt-in constructor argument, such as new URL(..., { noTrim: true }). Refs: Removing trailing C0 control or space at basic URL parser makes difference with override #542 (comment)
2. Allows basic URL parser to use c0 control or space
3. Remove c0 control or space always

[annevk]

Why should it show the same result? They're not the same API.

[watilde]

It always requires the override state when users want to put \x00 at the end of the URL so that I was wondering if the basic parser should provide a way to reproduce the same result with the override state's result when an input has the same value which is \x00 at the end in this case.

[annevk]

That might be reasonable, but should be an opt-in constructor argument of sorts I think. E.g., new URL(..., { noTrim: true }).

[watilde]

Right. The optional constructor argument design would be better for backward compatibility. I just updated the description of this PR to address the discussion.

[domenic]

FWIW I would prefer to always remove, in both APIs. It would be nice if the URL data model could guarantee no trailing C0 control or space instead of having the trimming being a parsing quirk.

[annevk]

The data model already guarantees it, no? It ends up ending with %00, not U+0000. Which is also why it seems reasonable to allow the parser to do that transformation for you if you want it.

I doubt we can change the API generally and given that the API is for individual components it's already a very different proposition. Why should port trim them, for instance?

[annevk]

Compared to other API requests we got this hasn't gotten a lot of interest so I'm inclined to close this until we see more of a demand in libraries.