Ability to access HTTP/2 pseudo headers

[GlenDC]

Is your feature request related to a problem? Please describe.

It seems by design from what I'm reading that we're not able to access the HTTP/2 pseudo headers.
So the answer might be no, but if so a resolution might be at the very least that we document this somewhere more clearly,
so for now it is pretty unclear for a newcomer IMHO.

Yes, we can access these values in other ways (e.g. req.method, req.uri.authoritiy, req.uri.scheme, req.uri.path, etc..).
While the spec defines that:

• these pseudo headers must come before any regular http headers
• and method, scheme and path MUST be defined

It still leaves room for:

• the order beween these pseudo headers
• when the authority headers and such are given

Describe the solution you'd like

Is there a way to simply be able to get them as part of the regular headers? I mean the info was received when parsing it, so it's a bit of a shame it is lost by the time I can access the request.

Describe alternatives you've considered

• assembling the headers myself for logging / analytics: but that leaves room for error as I do not know their exact order or if a header that isn't required was really given or not;
• not use hyper and instead do it via more low level building blocks but that seems like reinventing the wheel (again) and probably making a lot of mistakes on the way;

[GlenDC]

While the title says otherwise I do feel this request falls in the realm of #2695.

It is well known that the pseudo header order is different for different clients (e.g. https://www.blackhat.com/docs/eu-17/materials/eu-17-Shuster-Passive-Fingerprinting-Of-HTTP2-Clients-wp.pdf is one of such papers discussing this matter). Currently I do not see a way for me to figure out he original order using Hyper, unless I'm missing something.

[seanmonstar]

It is by design that pseudo headers are not in the regular header map. I imagine we could improve a "versions" section of the docs to clarify details like this.

The exact order is not supposed to matter, so I'm not especially keen on putting ourselves in a place where it does. (I feel like passive fingerprinting, while obvious, is bad for privacy, and has the possibility of being extremely brittle. Such as if a client were to add in an RNG to determine the order of psuedo headers before each request.)

[GlenDC]

Adding an RNG might actually trigger alerts of. These passive fingerprints are reliable as browsers have pretty straight forward logic for these and all have them use collections which respect original insert order.

Fingerprinting are not isolated silos but rather to be seen together to detect inconsistencies. E.g. if you advertise you're a firefox macos user, than it would be weird if now and then your pseudo headers tell you all kind of different stories.

I do wonder why these are not part of the regular header map? And even so, why not be part of some separate map in that case (be it an opt-in feature). It could still allow the default behaviour today but at least if desired that you can see what pseudo headers were sent and how. And the other way around, allow a client to insert these headers manually, and use these (in order inserted) instead of the defaults that would otherwise be used.

Again I think the default how it is today make sense, but this seem like a isolated and simple enough matter that I have hopes we can also allow the more advanced use cases of pseudo headers here, where customisation (client) and observability (server) might be desired? They do not have to exclude one another I imagine?