Proposal: Removing HEADERS frame

[Hasan Khalil]

HEADERS provide little use[1], so I'd like to see them removed from the spec. Here's what I've got in mind:

1. We remove the HEADERS frame from the specification.
2. Instead of just recommending, we require that all request and response headers be sent with SYN_STREAM and SYN_REPLY respectively.
3. Servers shall send SYN_STREAM back to clients to indicate that it is making a server push 'request' on behalf of the client. Any request details (headers, etc.) that the server may be using to generate its response are included.
4. Servers shall use SYN_REPLY to initiate the response to the 'request' in (3). No DATA frames may be sent in between (3) and (4) for the stream initiated in the former.

This allows server-side implementors to announce to the client that it's making a server push request on its behalf before it actually handles said request and retrieves response headers to be sent via SYN_REPLY or response data to be sent via DATA.

Thoughts?

    -Hasan

[1] Really, there are two uses for HEADERS that I see: (a) announcing a server push without , which can be better modelled as (3) above and (b) trailing headers, which many believe to be bad/dangerous/ugly and mostly unimplemented.

[Antonio Vicente]

So server push would be SYN_STREAM(even stream id X, associated stream
id set) with only :scheme, :host, :url and :version, followed by
SYN_REPLY(stream id X) with all the reply headers.

This would replace the current server push proposal that allows use of
either a single SYN_STREAM with all the headers, or a SYN_STREAM with
some headers followed by a HEADERS frame with the rest. I think that
requiring that the server send two frames in all cases makes the
protocol more consistent, and therefore simpler. Sending the "pushed
request" and "response" headers separate from each other also seems
cleaner.

I like the idea of less frame types although really the only
difference between SYN_REPLY and HEADERS is the control frame id.

-antonio

[Simone Bordet]

Hi,

On Sun, Feb 26, 2012 at 21:35, Hasan Khalil <hkh...@google.com> wrote:
> HEADERS provide little use[1], so I'd like to see them removed from the
> spec. Here's what I've got in mind:
>
> We remove the HEADERS frame from the specification.
> Instead of just recommending, we require that all request and response
> headers be sent with SYN_STREAM and SYN_REPLY respectively.
> Servers shall send SYN_STREAM back to clients to indicate that it is making
> a server push 'request' on behalf of the client. Any request details
> (headers, etc.) that the server may be using to generate its response are
> included.
> Servers shall use SYN_REPLY to initiate the response to the 'request' in
> (3). No DATA frames may be sent in between (3) and (4) for the stream
> initiated in the former.
>
> This allows server-side implementors to announce to the client that it's
> making a server push request on its behalf before it actually handles said
> request and retrieves response headers to be sent via SYN_REPLY or response
> data to be sent via DATA.
>
> Thoughts?

It's still not clear to me what is the solution for handling "100
Continue" HTTP responses in SPDY.

And no, I am not convinced that PING can do that, while HEADERS would
IMHO fit the bill.

From RFC 2616:
"The purpose of the 100 (Continue) status (see section 10.1.1) is to
allow a client that is sending a request message with a request body
to determine if the origin server is willing to accept the request
(based on the request headers) before the client sends the request
body."

I read this as semantically different from a ping: the client needs to
receive a 100 Continue response *and* another response with either 200
OK or a final status (with headers).

Simon
--
http://cometd.org
http://intalio.com
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

[Antonio Vicente]

There were two threads about 1xx response codes and 100-continue in
the past 6 months. It is unclear to me if 100-continue support is
needed given that the protocol supports per-stream flow control and
allows servers to send window updates back to the client only when
they are willing to continue accepting data on that stream. There is
also RST_STREAM with informative error codes, which could serve a
purpose similar to that of HTTP response code 417 Expectation failed.

I don't think consensus on 100-continue/1xx support was reached.
There was a proposal for a new STREAM_CONTINUE frame that carries the
100 response code and nothing else. There seems to not be a lot of
enthusiasm for support of 100-continue in spdy, but it might be
something we would need to somehow support anyway.
-antonio

[Simone Bordet]

Hi,

On Mon, Feb 27, 2012 at 09:11, Antonio Vicente <a...@google.com> wrote:
> There were two threads about 1xx response codes and 100-continue in
> the past 6 months.  It is unclear to me if 100-continue support is
> needed given that the protocol supports per-stream flow control and
> allows servers to send window updates back to the client only when
> they are willing to continue accepting data on that stream.  There is
> also RST_STREAM with informative error codes, which could serve a
> purpose similar to that of HTTP response code 417 Expectation failed.
>
> I don't think consensus on 100-continue/1xx support was reached.
> There was a proposal for a new STREAM_CONTINUE frame that carries the
> 100 response code and nothing else.  There seems to not be a lot of
> enthusiasm for support of 100-continue in spdy, but it might be
> something we would need to somehow support anyway.

One of the reasons that prompted me to reply to this thread was indeed
that, given that a HEADERS-based solution fits intuitively for
100-Continue, it would be questionable to remove HEADERS to introduce
STREAM_CONTINUE.

Perhaps it's even possible to simulate a 100-Continue with
unidirectional streams, but I think a definitive solution should be
found for 100-Continue before removing HEADERS.

Thanks,

[Ryan Hamilton]

+1.  This proposal seems to significantly simplify the semantics of server push, as well as removing the ambiguity around the handling of additional HEADER frames in a traditional HTTP request.

[Costin Manolache]

I also like HEADERS for the potential use to send metadata ( computed at the end ) - what the trailing/chunk headers were supposed to do. It's true they are not used much - but 

that doesn't seem a good argument in spdy ( neither are headers > 64k or client cert). 

If the concern is the ambiguity/risk of head/tail headers - how about replacing it with a "OOB" frame - it could be used for 100 continue, push, extensions like adding crc/signature to payload - but the oob data will never be mixed up with the headers.  Window update is another example of out of band data associated with the stream.

Costin

[Tatsuhiro Tsujikawa]

+1
Let's remove HEADERS. It is too generic and brings many unnecessary
ambiguous usage pattern.
Using SYN_STREAM+SYN_REPLY for server push makes much more sense to me.

2012年2月28日1:39 Ryan Hamilton <r...@google.com>:

[Hasan Khalil]

If you are so inclined, I'm sure we'd all be happy to hear about an OOB frame proposal from you, but I don't think that we need to burden this thread with such a discussion.

Killing of HEADERS frames is a boon for implementors both client-side and server-side, and, in my opinion, doesn't significantly restrict scope on what can be done over SPDY -- only a little bit on how you can do it.

Hypothetical extensions aside, I don't see any strong arguments against killing HEADERS as proposed.

    -Hasan

[Mike Belshe]

I'm not quite sure I follow your proposal, can you augment it with pseudo-stream IDs so I can follow which stream is which?  I think you're saying you want the server to issue both a SYN_STREAM and a SYN_REPLY for a pushed stream?

e.g.

-> client SYN_STREAM #1

<- server SYN_REPLY #1

<- server SYN_STREAM #2, associated to stream #1

<- server SYN_REPLY #2, associated to stream #1

<- server DATA #1

<- server DATA #2

<- server DATA #1

<- server DATA #2

   (etc)

If I have it right, then you didn't really change anything in the protocol complexity wise.  You're still allowing for the early announcement of a pushed URL (which is good), but you still have the equivalent of a headers frame, now just overloaded as a SYN_REPLY.   

But a downside to this is that SYN_STREAM and SYN_REPLY are no longer always from opposite endpoints - sometimes they are and sometimes they aren't.  I'd argue that the HEADERS is a better way to structure this case, because it leaves SYN_STREAM and SYN_REPLY symmetric.

Also, by abandoning the HEADERS frame altogether, it becomes even more unclear how to deal with HTTP 1xx responses and trailing headers, areas where we've wanted to improve, not make worse....

Is this really a simplification at all?  Keep in mind that we could cycle around on syntax forever.  This change does not alter performance and does not add any user benefit.

Mike

[William Chan (陈智昌)]

On Wed, Feb 29, 2012 at 3:41 PM, Mike Belshe <mbe...@chromium.org> wrote:

I'm not quite sure I follow your proposal, can you augment it with pseudo-stream IDs so I can follow which stream is which?  I think you're saying you want the server to issue both a SYN_STREAM and a SYN_REPLY for a pushed stream?

e.g.

-> client SYN_STREAM #1

<- server SYN_REPLY #1

<- server SYN_STREAM #2, associated to stream #1

<- server SYN_REPLY #2, associated to stream #1

<- server DATA #1

<- server DATA #2

<- server DATA #1

<- server DATA #2

   (etc)

If I have it right, then you didn't really change anything in the protocol complexity wise.  You're still allowing for the early announcement of a pushed URL (which is good), but you still have the equivalent of a headers frame, now just overloaded as a SYN_REPLY.   

You have it right.

 

But a downside to this is that SYN_STREAM and SYN_REPLY are no longer always from opposite endpoints - sometimes they are and sometimes they aren't.  I'd argue that the HEADERS is a better way to structure this case, because it leaves SYN_STREAM and SYN_REPLY symmetric.

I minorly disagree. I don't feel strongly here though.

 

Also, by abandoning the HEADERS frame altogether, it becomes even more unclear how to deal with HTTP 1xx responses and trailing headers, areas where we've wanted to improve, not make worse....

I've forgotten about HTTP 1xx responses, and need to page that discussion back into memory. But I don't feel bad about ditching trailing headers support.

 

Is this really a simplification at all?  Keep in mind that we could cycle around on syntax forever.  This change does not alter performance and does not add any user benefit.

It's a simplification due to removing the need to support trailing headers. There is added complexity needed to support a HEADERS frame coming at any point in time. I think that's the crux of it. I agree the rest is mostly syntactical, which is why I don't feel strongly about it. I'll go re-read the HTTP 1xx discussions.

[Eric Ceres]

Hi,

If the fear is random headers then why not spec that headers frame can not come during data transmission (from the server). It should be simple to only allow it before first data frame and after last data frame. Any header during data stream (from the server) could result in an error  reset. 

- Eric Ceres

[Roberto Peon]

What Mike said, but s/(which is good)/(which is essential)/

I think that request vs response should always be clear-- we have enough trouble distinguishing to/from server/client already.

Server push happens in response to the original request stream. It should thus use SYN_REPLY. I don't see it as a separate request, thus I don't get using SYN_STREAM for it.

I don't care if we change the name of the headers frame.

-=R

On Wed, Feb 29, 2012 at 3:41 PM, Mike Belshe <mbe...@chromium.org> wrote:

[Hasan Khalil]

I agree that request vs response should always be clear.

The way I see it, server push happens when the server decides to make a 'fake' or implicit request on behalf of the client. As you mention, it's essential for the client to be aware that this 'request' is being made on its behalf before work involved in responding to said request -- in the case of a proxy, this may mean making an actual request to somewhere else -- is done and the response sent back. The proposal at hand satisfies this requirement and also, I think, clarifies the request/response distinction. Under the proposal the following changes are made:

SYN_STREAM is always a request and must always contain all request headers with no response headers (as opposed to current behavior, wherein SYN_STREAM can contain request headers combined with response headers for server push).

SYN_REPLY must be used for all response headers.

    -Hasan