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

Re: END_STREAM flag and trailing headers

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 8 May 2014 15:29:26 -0700
Message-ID: <CABkgnnWHh0FEw8iBJm_-F8Z2wAF5Pp9mgePS5bsxFnW4z4-Ldg@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 8 May 2014 15:14, Greg Wilkins <gregw@intalio.com> wrote:
> However, if I have this right, this now means that a PUSH_PROMISE, must have
> data?    I don't see why that should be, as it may be that a server
> discovers needs to push 30x redirects.

PUSH_PROMISE has no data associated with it directly.  A PUSH_PROMISE
is a single frame (plus CONTINUATION) that does not end a stream
because it sits on another stream (we use the term "associated stream"
in the draft).  It has no impact on the state of the associated
stream, and doesn't end that stream.

PUSH_PROMISE includes a synthesized request.  It's the response that
results from the PUSH_PROMISE (on the promised stream) that could
contain data.  That response follows the normal structure for a
stream, it's just that PUSH_PROMISE causes the promised stream to
start later in the normal state machine, since the request is carried

So it's perfectly valid to push a 3xx redirect.  Or even a 5xx if you
really feel like it.  Entity bodies are merely optional on pushed
responses.  (They are not at all possible on pushed requests, despite
there being some DAV cases that describe uses for entity bodies on
safe methods, we decided against supporting that complication.)

Say that you get a request for /foo on stream 7.  Maybe you want to send this:

Stream7: PUSH_PROMISE GET /bar ;Stream8
Stream7: HEADERS 200 OK (for /foo)
Stream7: DATA ...for /foo
Stream8: HEADERS[END_STREAM] 3xx Location: /bar100
Stream7: PUSH_PROMISE GET /bar100; Stream10
Stream10: HEADERS 200 OK
Stream10: DATA .... for /bar (actually /bar100)

> Actually I think that it is poor protocol layering to have to interpret the type of a
> frame in order to workout stream boundaries.

I used to think the same, and if you care to do some git spelunking,
there's good evidence of that.  I think that it was at the point that
I went through the process of working through the state machine that I
changed my mind.  What we've actually done here is conflate some of
the stream control functions with the application semantics functions
in the interests of efficiency.
Received on Thursday, 8 May 2014 22:29:53 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:42 UTC