Re: adding Header Continuation

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 <grmocg@gmail.com> 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.
> 
> 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 <martin.thomson@gmail.com> wrote:
> On 19 May 2013 20:29, Mark Nottingham <mnot@mnot.net> wrote:
> > 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
> 
> 

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

Received on Tuesday, 28 May 2013 05:33:14 UTC