4 ms·
RFC for HPAC here. https://datatracker.ietf.org/doc/html/rfc7541 https://datatracker.ietf.org/doc/html/rfc7541 A shared client-server compression state is real
by staticassertion 5y ago
RFC for HPAC here.
https://datatracker.ietf.org/doc/html/rfc7541 https://datatracker.ietf.org/doc/html/rfc7541
A shared client-server compression state is really weird. Can someone explain why this approach was chosen? I'm assuming that the idea here is to ensure efficiency for short strings by essentially keeping a synchronized dictionary?
- Matthias247 5y agoYes. That’s the idea - in combination with the idea that requests to the same server are often repetitive (they might have a lot of common headers). And „synchronized dictionary“ is basically the idea behind. Unfortunately http/2 didn’t really give implementations a chance to opt out of that complexity by setting the table size to 0 - the default is 4kB and manipulating it triggers a race condition which might fail requests. That part is thankfully nicer in http/3, and both peer äs have to opt into using dynamic compression via a synchronized header table to support it.