Subject: draft-ietf-httpbis-http2-latest, 8.1 HTTP Request/Response Exchange

From: Kari Hurtta <[email-masked]>
Date: Sun, 06 Jul 2014 16:05:25 +0000

Hypertext Transfer Protocol version 2
draft-ietf-httpbis-http2-latest
July 5, 2014
http://http2.github.io/http2-spec/

8.1 HTTP Request/Response Exchange
http://http2.github.io/http2-spec/#HttpSequence

> Otherwise, frames MAY be interspersed on the stream between these
> frames, but those frames do not carry HTTP semantics. In particular,
> HEADERS frames (and any CONTINUATION frames that follow) other than
> the first and optional last frames in this sequence do not carry HTTP
> semantics. 

So what is recipient supposed to do when it receives header block
which is not first header block and do not include END_STREAM flag ?

I see two different possibilites

1) This header block is part of data (request or responce body)

or

2) this header block is ignored

( Clearly this is not stream error of type PROTOCOL_ERROR
  because it seems to be allowed. )

If header block is part of data then it can converted to

header-name: header values CRLF
header-name: header values CRLF
and so on...
CRLF

block and treat similar than data from DATA -frame.

( or process directly, if data from DATA frames is parsed
  immediately and headers are expected on body (for example 
  on multipart/* -type bodies) on that point of data).

If header block is ignored then it is part of some extension.

But I do not see that specified.

/ Kari Hurtta

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Jul 2014 09:45:37 -0700

> 2) this header block is ignored

This is the answer, implied by "do not carry HTTP semantics."
However, this falls into the same category as END_SEGMENT; it doesn't
contribute to HTTP, though it might be used for something like
thewebsocketprotocol.  https://github.com/http2/http2-spec/issues/537
applies in both regards.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Jul 2014 10:47:21 -0700

On 7 July 2014 09:51, Kari Hurtta <[email-masked]> wrote:
> That was not very clear because "do not carry HTTP semantics"  may also
> mean that "these headers are not HTTP -headers". Headers, which
> are part of some media type (say multipart/*), are not HTTP -headers.

The mime headers that are part of multipart/* are not visible to HTTP.
They live in DATA frames.

Honestly, I'd rather wait for the conclusion of #537 before making any
changes here.