h2
h2 copied to clipboard
hyperium
Need Control over Header Indexing in HPack
Presently, it seems that the Header/HPACK process in H2 is opaque. However, sometimes it is necessary to control how headers are indexed (or re-indexed) into the HPACK dictionary.
(e.g. https://tools.ietf.org/html/rfc7541#section-6.2.1 )
Specifically, I am writing a tool which pushes via Apple APN. It has requirements for some, but not all of its headers to be set differently, based on whether it is the first send of the request, or subsequent ones.
From Apple's docs : https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html
The :path value should be encoded as a literal header field without indexing
The authorization request header, if present, should be encoded as a literal header field without indexing
The appropriate encoding to employ for the apns-id, apns-expiration, and apns-collapse-id request headers differs depending on whether it is part of the initial or a subsequent POST operation, as follows:
The first time you send these headers, encode them with incremental indexing to allow the header names to be added to the dynamic table
Subsequent times you send these headers, encode them as literal header fields without indexing
This could be handled by creating a config object that is passed to the hpack encoder.
I would assume a http::HeaderMap<HpackEncodeStrategy> such that HpackEncodeStrategy directs the encoder. If the header map is empty, then the default strategy is taken.
I'm also pretty sure that those are recommendations and not requirements to use apple APN.
Actually, HeaderValue in the http crate already has set_sensitive, could that be used? Would it make sense to also add the flag to http::uri::PathAndQuery?
Sensitive indicates that it should use never indexed which means proxies cannot ever index it in the hpack table. It’s the strongest form.
Yea, we could add set_not_indexed or whatever if really necessary, but either way, set_sensitive would work in this case, since Apple is just recommending how to keep churn in the dynamic table low.
It would be nice to set the flags directly in HeaderValue
Maybe we should expand the interface slightly for HeaderValue in the http crate? If its intent is to serve all versions of HTTP, it seems like it would need to include the possible indexing flags.
I'm also pretty sure that those are recommendations and not requirements to use apple APN.
I'm starting testing on it now.. will see what happens :)