Re: [whatwg/url] URL serialiser does not produce idempotent strings if an opaque path has a trailing space and "exclude fragment" is true (Issue #784)

> I'd prefer to just escape only the last trailing space. It's simpler and the algorithm would be faster.
So I don't see any advantage in escaping all the trailing spaces, or am I wrong?

So, I think there is probably broad agreement that unescaped spaces are not ideal. Unfortunately, they are required for web compatibility, so we have to allow them as much as possible.

As part of this change, one or more trailing spaces that would previously have been unescaped would now be escaped. That's a change which has the potential to break some applications, but it is _equally_ breaking whether we escape one trailing space or all trailing spaces. There is no compatibility advantage to only escaping a single space - the same applications would break either way, and the remedy would be the same.

I can't think of another time where we escape only a single occurrence of a particular character, and leave all other instances of that character in the same URL component without escaping. Generally it's always "code point X is escaped in component Y". In that sense, saying that only a _particular_ space gets escaped feels to me to be more complex, and if I imagine the reaction of developers seeing that behaviour from the parser, I think it would seem stranger and more surprising.

If developers are working with URLs containing multiple trailing spaces, I think it is overall simpler and more predictable if the parser escapes all of those trailing spaces at once.

As for performance? The difference is negligible. We're talking about an edge case of an edge case of an edge case (multiple occurrences of unescaped trailing spaces in a URL with opaque path); the important thing is that the more common scenarios can be fast-pathed, and they can.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/784#issuecomment-1711774472
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/issues/784/1711774472@github.com>

Received on Friday, 8 September 2023 14:35:37 UTC