Re: HEADERS and flow control

On 22.05.2014 14:36, Martin Thomson wrote:
>>> You can't however reject a header block that you don't want. Not without
>>> also dumping the connection. Common state being what it is.
>> AFAIK, It is possible to do just corrupting the stream state, not connection
>> state (just mark things as failed and stop really emitting headers). Then upon
>> end of block, if things failed, try to deal with the corrupt stream.
> Yes, you can process the updates to the header table, but dump the
> output into the bitbucket and reset the stream.
This probably can be done as a header block is processed as a unit, but 
currently we have:

An endpoint receiving HEADERS, PUSH_PROMISE or CONTINUATION frames MUST 
reassemble header blocks and perform decompression even if the frames 
are to be discarded. A receiver MUST terminate the connection with a 
connection error (Section 5.4.1 
<http://tools.ietf.org/html/draft-ietf-httpbis-http2-12#section-5.4.1>) 
of type COMPRESSION_ERROR if it does not decompress a header block.

>> These kind of cases are very nasty to handle in streaming manner, because the
>> webserver can't dispatch execution before almost the end of block.
> Good point.  That's why a good implementation will put all the routing
> fields at the start.  But that's not possible if the routing fields
> are pulled from the reference set, which I just realize is highly
> likely for things like :scheme and :authority.  Bleargh.
>
For intermediaries this seem to mean they need to do store and forward 
instead of streaming. If they still want to do streaming they are 
vulnerable to malicious clients not sending continuation frames.