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

Re: Some general SPDY feedback / questions

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 7 Aug 2012 10:43:58 -0500
Cc: Roberto Peon <grmocg@gmail.com>, <ietf-http-wg@w3.org>
Message-Id: <E67EC141-85D9-4F64-920F-9F3EAB251DC7@mnot.net>
To: James M Snell <jasnell@gmail.com>

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.


Mark Nottingham
Received on Tuesday, 7 August 2012 15:44:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC