Subject: 1xx (informational) responses affect on stream management

From: Matthew Cox <[email-masked]>
Date: Tue, 5 Aug 2014 18:05:10 +0000

In section 8.1 it describes a HTTP message with the following:

   1.  for a response only, zero or more HEADERS frames (each followed
       by zero or more CONTINUATION frames) containing the message
       headers of informational (1xx) HTTP responses (see [RFC7230],
       Section 3.2 and [RFC7231], Section 6.2), and

   2.  one HEADERS frame (followed by zero or more CONTINUATION frames)
       containing the message headers (see [RFC7230], Section 3.2), and

The issue I have with this is that #1 requires interpretation of the HEADERS payload to correctly transition the state of the stream receiving that frame since the status code has to be found to determine whether this is an informational response or not.  As far as I can tell this is the first time the stream state has been affected by the payload of the frames.

Currently I'm able to do all of my stream state management/transitions without having to do any interpretation of the payload.  With draft-14 I now need to know what is in the payload, so that the stream can correctly identify what subsequent frames are allowed.  In my mind this crosses a layer boundary.

I purpose that we add a new flag to the HEADERS frame that indicates whether this is an informational HEADERS frame or the final HEADERS (status-code) frame.  With this, section 8.1 could be described without any interpretation of the payload allowing stream states to be managed based purely on the frame.

Thanks,

Matthew

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Aug 2014 13:06:46 -0700

On 5 August 2014 11:05, Matthew Cox <[email-masked]> wrote:
> Currently I’m able to do all of my stream state management/transitions
> without having to do any interpretation of the payload.  With draft-14 I now
> need to know what is in the payload, so that the stream can correctly
> identify what subsequent frames are allowed.  In my mind this crosses a
> layer boundary.

Maybe you can instead consider this in two parts:

a) a valid sequence of frames, for which the combination of "zero or
more" and "one" turns into "one or more"

b) a valid HTTP response, for which the value of ":status" becomes relevant

---

From: Simone Bordet <[email-masked]>
Date: Tue, 5 Aug 2014 23:30:30 +0200

Hi,

> b) a valid HTTP response, for which the value of ":status" becomes relevant

I don't understand this answer in the context of the original
question, can you please expand ?

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---

From: Martin Thomson <[email-masked]>
Date: Tue, 5 Aug 2014 14:43:20 -0700

> question, can you please expand ?

Matthew seems concerned about having to enforce frame cardinality
rules based on frame contents.  This is a legitimate concern.
Previously, a request or response was one HEADERS, some number of DATA
and maybe another HEADERS.  Simple.

With the 1xx change, now you can have 0..n HEADERS frames before that
sequence and you can't know if they are valid until a) you look at
:status, and b) you receive the next frame (because a non 1xx status
is only valid if it is followed by DATA, or maybe trailers for the
particularly cunning or perverse).

All I'm suggesting is that you can divide the problem into two: look
at the frames, if the count is good pass them on.  Then, at the HTTP
layer, when you are looking for other things, you can check :status,
along with all the other pseudo-header stuff.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 6 Aug 2014 08:37:55 +1000

On 6 August 2014 04:05, Matthew Cox <[email-masked]> wrote:

> without having to do any interpretation of the payload.

That is a good thing to strive for !  (and it is one of the things I
dislike most about the draft that we have to look at frame type before we
can look for END_STREAM flag).

But, if we are ever to carry non-HTTP protocols over streams (eg
websocket), then I think it is really important to not enforcing HTTP
semantics in the streaming layer. So I don't think the HTTP semantics
described in 8.1 are something that you need to tracked in the framing
layer / stream management.

It should not be the framing layers job to police HTTP semantic
consistency.  For example checking that any content-length sent is the same
as the amount data actually sent is not something that should be done in
the framing layer, nor if the status value is actually an integer nor any
of the many other ways you can create an invalid HTTP message.

So I think your streaming layer should pretty much allow any frame type
sequence through, and only look at frame type just enough to look for
END_STREAM.....   maybe it must also handle CONTINUATIONs and END_HEADERS
because of their particular requirements  (more conflation of HTTP
semantics to the framing layer).    But let it be relaxed about non-http
frame sequences in a stream, as hopefully we eventually will see non-http
travelling over streams.

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.