RE: REFUSED_STREAM and HPACK

Yes, even for a refused stream, the HPACK decompression has to be done. This is stated in the last paragraph of 4.3:
"... 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) of type COMPRESSION_ERROR if it does not decompress a header block."

However, it would probably be helpful to recall it in 8.1.4.

Hervé. 

> -----Original Message-----
> From: K.Morgan@iaea.org [mailto:K.Morgan@iaea.org]
> Sent: lundi 30 juin 2014 13:44
> To: ietf-http-wg@w3.org
> Subject: REFUSED_STREAM and HPACK
> 
> (*Bold* emphasis added.)
> 
> 
> 
> Section 7
> 
> REFUSED_STREAM (0x7): The endpoint refuses the stream prior to performing
> *any application processing*, see Section 8.1.4 for details.
> 
> 
> 
> Sections 8.1.4
> 
> The REFUSED_STREAM error code can be included in a RST_STREAM frame to
> indicate that the stream is being closed prior to *any processing* having
> occurred
> 
> 
> 
> Question: Must an endpoint that is refusing a stream always process the
> headers and update its HPACK state?  If so, the text in 8.1.4 should probably be
> more specific and say "any _application_ processing".  And perhaps explicitly
> clarify that HPACK state has to be updated before refusing the stream.
> 
> 
> 
> This email message is intended only for the use of the named recipient.
> Information contained in this email message and its attachments may be
> privileged, confidential and protected from disclosure. If you are not the
> intended recipient, please do not read, copy, use or disclose this
> communication to others. Also please notify the sender by replying to this
> message and then delete it from your system.

Received on Monday, 30 June 2014 13:32:43 UTC