W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014


From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Mon, 30 Jun 2014 13:31:51 +0000
To: "K.Morgan@iaea.org" <K.Morgan@iaea.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E532D77D34@ADELE.crf.canon.fr>
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.


> -----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
> (*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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC