3 ms·
I'm curious about how the Header tables are supposed to work. How does the client reliably know which request was last received by the server? In the example >
by adam-a 12y ago
I'm curious about how the Header tables are supposed to work. How does the client reliably know which request was last received by the server? In the example
> method: GET
> path: /resource
> ...
can be followed by just
> path: /other_resource
but how do I know a badly behaving router didn't delay a DELETE request from earlier? Do I have to manually table all my responses to make sure there are no potentially dangerous requests on the wire?
- Lukasa 12y agoThere are a few key points here. First, Ilya's slides are out of date. The reference set got removed (it was a complexity nightmare), so there's a bit less efficiency in deltas but a substantially simpler algorithm for header sets. As for your badly behaved router, there are two options. The first is that it's a router, not a proxy. In that case, the strict ordering of TCP ensures that there's no problem here. A router cannot cause the server to miss a request without knowing about it. Assuming by 'router' you meant 'proxy', the key here is that HPACK compression state is hop-by-hop, not end-to-end. That is, HPACK compression state is only synchronised at each end of a TCP connection. The strict ordering of TCP ensures that those two ends cannot be confused about the order of requests. Across TCP connections, there's new HPACK state.
- adam-a 12y agoAh thanks for explaining it. I'm so used to thinking of http as a set of concurrent requests, but as a single stream optimisations like this make sense.