Subject: adding Header Continuation

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 May 2013 13:29:50 +1000

Roberto submitted a pull request for header continuation:
  https://github.com/http2/http2-spec/pull/98

Without going into the fine details of the text, are we ready to have such a thing?

My reading is that people are OK with this, at least to the point of putting it in the implementation draft (i.e., implementation experience may cause us to pull it back out again).

Speak up if you disagree.

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Mon, 20 May 2013 09:25:16 -0700

I am ok with putting this in for now so long as the possible security
risk is acknowledged. In general, however, I believe the risk is quite
low.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 20 May 2013 10:02:52 -0700

> Without going into the fine details of the text, are we ready to have such a thing?

Yes.  But.

I think that we need to be a little clearer on what happens when size
limits are exceeded.

grmocg wrote:
> If I recall correctly, there currently isn't an explicit limit on header size in HTTP. Unless we're willing to impose such, it is up to the implementation to reject things which are too large by RESETTING the stream. That case probably does need more expounding, though.

Resetting a stream isn't going to be possible, unless the receiver
first applies any changes to local compression state.  I remain
concerned that the header compression scheme will need to deal with
the same issue.

I'd like to see a discussion resolve on what strategy(ies) we want to
permit for dealing with bad peers for oversized stuff, for this and
perhaps also frames in general.  A generally applicable strategy seems
plausible.  In that discussion we should cover whether we permit the
declaration of size limits.

--Martin

---

From: Roberto Peon <[email-masked]>
Date: Mon, 20 May 2013 12:07:51 -0700

Further expounding:

The contents of header frames MUST be processed by the compression context,
even when the stream has been reset. If this is unacceptable, the receiver
MAY terminate the session with the appropriate error code indicating why.

In other words, yes, agreeing about the fact that state must be sync'd.
The above is useful even when a max size has been negotiated, since servers
may decide to reset streams for many reasons

-=R

On Mon, May 20, 2013 at 10:02 AM, Martin Thomson
<[email-masked]>wrote:

> > If I recall correctly, there currently isn't an explicit limit on header
> size in HTTP. Unless we're willing to impose such, it is up to the
> implementation to reject things which are too large by RESETTING the
> stream. That case probably does need more expounding, though.
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 May 2013 15:32:37 +1000

OK, that sounds separable. I'm accepting the pull request and opening an issue to track the effect of headers on compression context <https://github.com/http2/http2-spec/issues/102>. 

On 21/05/2013, at 5:07 AM, Roberto Peon <[email-masked]> wrote:

> Further expounding:
> 
> The contents of header frames MUST be processed by the compression context, even when the stream has been reset. If this is unacceptable, the receiver MAY terminate the session with the appropriate error code indicating why.
> 
> The above is useful even when a max size has been negotiated, since servers may decide to reset streams for many reasons
> 
> 
> 
> -=R
> 
> 
> On Mon, May 20, 2013 at 10:02 AM, Martin Thomson <[email-masked]> wrote: