RE: Some general SPDY feedback / questions

A mechanism like the 100-continue is critical for supporting requests containing entity data that results in authentication needed, redirect, or other "intermediate "responses in an efficient and robust manner. It allows the client to send the headers which the server can then use to determine whether it can accept the data and as a result give a go-ahead to the client. You don't want the client to start sending a lot of body data if it has to redo the request.

You can approximate this behavior with careful use of flow-control credits but it will inherently be much cruder because there is no way to separate cleanly on a header/body boundary. As a result it will likely result in wasted bytes transmitted -- something we want to avoid with HTTP/2.0.

Expect on the other hand is in general a failed experiment in my opinion -- you can't retrofit such semantics into an existing protocol.

Henrik

-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net] 
Sent: Tuesday, August 07, 2012 08:44
To: James M Snell
Cc: Roberto Peon; ietf-http-wg@w3.org
Subject: Re: Some general SPDY feedback / questions


On 19/07/2012, at 1:37 AM, James M Snell <jasnell@gmail.com> wrote:

> 
> On Jul 18, 2012 2:35 PM, "Roberto Peon" <grmocg@gmail.com> wrote:
> >[snip]
> >> 3. How are Informational 1xx Status Codes handled? The current SPDY draft does not appear to support "provisional responses". 
> >
> >
> 
> Thank you for the reference to the thread. After reading through it one thing became obvious: while it would likely not be difficult to provide support for a 100-continue like mechanism within spdy, the protocols current design would essentially require a suboptimal hack in order to retain existing http/1.1 semantics and preserve spdy-to-http1.1 pass through or would require that we design a new similar mechanism, optimized for spdy that changes an aspect of http/1.1 semantics.
> 
> As Mark  has pointed out recently, however, our job here currently is to only define a new transport for http and not to change existing http semantics. So i am at a bit of a loss as to what the charter will let us do in this case.
> 
> Mark... any guidance?

It's a good question. I know that it has come up often on the SPDY list (sometimes raised by me ;).

I'd characterise expect/continue as being on the lighter borders of a grey area; it is used, but it does cause interop problems.  HTTPbis hasn't decided to deprecate it, so it does form part of the semantics of HTTP (unlike, for example, chunk extensions, which we have deprecated).

However, that doesn't preclude us from deciding to not support it in HTTP/2, *if* we can get a good consensus around doing so. I'd be inclined to have a somewhat higher bar for doing so, however.

I'd be interested to hear comments from others, of course.

Cheers,

--
Mark Nottingham
http://www.mnot.net/

Received on Tuesday, 7 August 2012 16:06:10 UTC