Subject: #557: Intra-message HEADERS frames

From: Mark Nottingham <[email-masked]>
Date: Sun, 20 Jul 2014 15:43:48 -0400

<https://github.com/http2/http2-spec/issues/557>

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?

Regards,

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 20 Jul 2014 21:43:50 +0000

In message <[email-masked]>, Mark Nottingham wri
>part of an HTTP request or response.

Is there a HTTP/2 need for this functionalty, or is this
some attempt to carve out space to tunnel other stuff under the
disguise of HTTP/2 ?

I think we should reserve HEADERS exclusively for HTTP semantics,
and make thel appearance of HEADERS in any other context should be
a protocol error.

If people want to tunnel other protocols through HTTP/2, they should
define the necessary frame types for it.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: James M Snell <[email-masked]>
Date: Sun, 20 Jul 2014 15:01:08 -0700

In the absence of an end to end extensibility model at the framing layer,
no there's no need for intrastream header blocks.

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 21 Jul 2014 12:00:52 +1000

> Do we need to say anything else here, or can we go ahead and close this

I'm happy with that wording.   Implies ignorability, which helps the
prospects for future extensions to work.

Although as implementations have to decode them to keep headertable up to
date, perhaps a some extra words saying implementations should be aware
they could be used for DoS, which is a little different to HTTP headers, as
implementations will be expanding those and checking the size, while
ignored frames might not be checked.

cheers

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Jul 2014 06:07:05 -0700

> 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.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Jul 2014 10:08:28 -0400

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

Cheers,

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 22 Jul 2014 14:41:26 +0000

In message <[email-masked]>, Mark Nottingham wri

>- PROTOCOL_ERROR upon a HEADERS where not expected

+1

---

From: Alvaro Lopez Ortega <[email-masked]>
Date: Tue, 22 Jul 2014 16:41:06 +0200

On Tue, Jul 22, 2014 at 4:08 PM, Mark Nottingham <[email-masked]> 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:
>

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 <[email-masked]> wrote:
> >> 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).
> >

-- 
All the best,
Alvaro

---

From: James M Snell <[email-masked]>
Date: Tue, 22 Jul 2014 08:16:23 -0700

Agree with PHK here. Since the decision has been made not to have an
end-to-end extensibility model in the framing layer, ignored
interspersed HEADERS frames that are not flow-controlled become a DoS
vector. At this point, there is absolutely no reason whatsoever to
have interspersed HEADERS frames.

- James

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Jul 2014 08:41:19 -0700

> - PROTOCOL_ERROR upon a HEADERS where not expected

I've already done this, and it's consistent with our philosophy (not
that we are always perfectly consistent in that regard).

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Jul 2014 13:10:36 -0400

Sounds good.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 23 Jul 2014 12:13:53 +1200

> - PROTOCOL_ERROR upon a HEADERS where not expected

+1.

> - ignore a HEADERS that’s not expected

-1.

IIRC, the presented use case for this has been to maintain checksums on
HTTP/1.1 chunked payloads. That is far better done as a checksum field
on DATA if the proponents of that want to push for it (or make an
extension for payload integrity checking). chunked checksums being a
hop-by-hop feature anyway which does not traverse middleware at all well
these days.

Amos

---

From: Roberto Peon <[email-masked]>
Date: Tue, 22 Jul 2014 17:22:00 -0700

The other presented case was doing stuff like an RPC protocol on HTTP2, but
I suspect that is best done in an extension now.
-=R

On Tue, Jul 22, 2014 at 5:13 PM, Amos Jeffries <[email-masked]> 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:
> >