Use in HTTP2/3 Pseudo-Headers

[ethanresnick]

Apologies if this has been discussed before, but: I noticed that HTTP/3's definition of the :path pseudo-header (like the definition in HTTP/2) incorporates RFC 3986 by reference; I know that WHATWG URL and RFC 3986 diverge in places, so it struck me that this might cause some problems/ambiguities. Has this come up before and is it an issue?

Specifically, the H3 RFC says that :path:

Contains the path and query parts of the target URI (the "path-absolute" production and optionally a ? character (ASCII 0x3f) followed by the "query" production; see Sections 3.3 and 3.4 of [URI].

[annevk]

I think there are some subtle incompatibilities indeed. E.g., a browser can produce /%% as a path. I haven't attempted to write exhaustive web-platform-tests for this though. That would probably be good. Testing how clients and servers deal with such "incorrect" (from the perspective of the HTTP specification anyway) paths would be good too. The result of such testing we can then use to determine where we need to make changes.

[mnot]

Anne AIUI most of your current testing regards what's reflected in JS and in the UX, not on the wire, correct?

[annevk]

I have done some on-the-wire-testing in the past and there's likely some WPT coverage, but not as exhaustive as I'd like to properly resolve this issue. That is, I have confirmed in the past that browsers can emit URLs RFC 3986 cannot parse, but that's about it.

[ethanresnick]

@annevk Ok, well, I have no idea what the fix is, but I'm glad I was able to highlight something real, at least :)

(@mnot Selfishly, while I have you and if you have time, I'd still love your opinion on these potential errata in the HTTP Caching rfc, and possibly this related issue too. I think the biggest issue there is about the "ranking preferences" with Vary + Accept. /end my hijacking of this issue.)

[mnot]

@ethanresnick they're on the queue.