Re: #557: Intra-message HEADERS frames

On Tue, Jul 22, 2014 at 4:08 PM, Mark Nottingham <mnot@mnot.net> wrote:

> I don’t hear a strong direction on this issue from the WG, so I’m inclined
> to let the editor take the lead here unless strong opinions emerge (keeping
> in mind the changes to allow a non-final status code, which means the
> wording needs to be a bit different here).
>
> The choices seem to be:
>
> - PROTOCOL_ERROR upon a HEADERS where not expected
>
> - ignore a HEADERS that’s not expected
>

I'd say PROTOCOL_ERROR would help to make the protocol more solid. Ignoring
the frames would introduce an level of laxity that could become a problem
in the future. I believe we'd be better off returning an error when
unexpected HEADERS frames are received.

Best,
Alvaro


On 21 Jul 2014, at 9:07 am, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> > On 20 July 2014 12:43, Mark Nottingham <mnot@mnot.net> wrote:
> >> Section 8.1 already says:
> >>
> >>> Header blocks after the first that do not terminate the stream are not
> part of an HTTP request or response.
> >>
> >> <http://http2.github.io/http2-spec/#HttpSequence>
> >>
> >> Do we need to say anything else here, or can we go ahead and close this
> issue?
> >
> > Here I'll point out my mess-up of this:
> >
> > A recent edit of Section 8.1 changed this to say:
> >
> >> A HEADERS frame (and associated CONTINUATION frames) can only appear at
> the start or end of a stream. An endpoint that receives a second HEADERS
> frame without the END_STREAM flag set MUST treat the corresponding request
> or response as malformed (Section 8.1.2.5).
> >
> > That's the alternative.  It's easy to back this out, depending on the
> > outcome of this discussion.
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>


-- 
All the best,
Alvaro