W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

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

From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Date: Sun, 06 Jul 2014 16:05:25 +0000
To: Martin Thomson <martin.thomson@gmail.com>, HTTPBIS working group mailing list <ietf-http-wg@w3.org>
CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Message-Id: <20140706160454.857BE5BC010@smtp4.welho.com>

Hypertext Transfer Protocol version 2
July 5, 2014

8.1 HTTP Request/Response Exchange

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


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

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
Received on Monday, 7 July 2014 09:40:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC