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?
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.
Ah 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.
> 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?