Should we escape \ in non-special non-opaque paths?

[TimothyGu]

Pros:

• Matches RFC 3986 and Go
• Might reduce path traversal vulnerabilities, for implementations that allow switching URLs from non-special to special schemes (i.e., all browsers)

Cons:

• Doesn't match any browser (though to be fair, Chrome and Firefox don't actually support non-opaque paths in non-special URLs, and Safari implements the current spec)

---

Originally suggested by @karwa in #651 (comment).

[annevk]

I think a lot of these proposals would be easier to do once Chrome has proper non-special URL support. For better or worse they're in the best position to judge what changes can be made.

[alwinb]

In any case. From the perspective of relative URLs, this is a good thing to do. The standard does not currently support parsing or serialising those, so decisions are often not checked against their implications for relative URLs either.

This means that it is left up to implementors of URL manipulation libraries to define a customised version of WHATWG URL normalisation that avoids reparse bugs for relative URLs and avoids as much ambiguity around scheme dependent parsing behaviour as possible.

Of course, the interpretation of \ being scheme dependent means that tools that produce relative, scheme-less URLs would better escape such occurrences, even if that does not agree with the normalisation as specified in the WHATWG standard. On the plus side, URLs with occurrences of \ are invalid, so I guess that isn’t so bad.