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://www.mnot.net/
>
>
>
>
>


-- 
All the best,
Alvaro

Received on Tuesday, 22 July 2014 14:41:39 UTC

Follow Lee on X/Twitter - Father, Husband, Serial builder creating AI, crypto, games & web tools. We are friends :) AI Will Come To Life!

Check out: eBank.nz (Art Generator) | Netwrck.com (AI Tools) | Text-Generator.io (AI API) | BitBank.nz (Crypto AI) | ReadingTime (Kids Reading) | RewordGame | BigMultiplayerChess | WebFiddle | How.nz | Helix AI Assistant