- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 7 Aug 2012 10:43:58 -0500
- To: James M Snell <jasnell@gmail.com>
- Cc: Roberto Peon <grmocg@gmail.com>, <ietf-http-wg@w3.org>
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 15:44:19 UTC