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

Re: Some general SPDY feedback / questions

From: Mike Belshe <mike@belshe.com>
Date: Tue, 7 Aug 2012 16:08:48 -0700
Message-ID: <CABaLYCu8tn=anqX6AV943s8YFSwGTE3CG5uCCVSEbgZLBnMygw@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: James M Snell <jasnell@gmail.com>, Roberto Peon <grmocg@gmail.com>, ietf-http-wg@w3.org
On Tue, Aug 7, 2012 at 8:43 AM, Mark Nottingham <mnot@mnot.net> wrote:

> 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.

I agree with Henrik about 100 Continues - HTTP/2.0 must support them.  (I
don't like 100's much, but that is a different issue :-)

The reason I think we need to support is because its a battle we don't need
to fight.  It was in HTTP/1.1, and a few people use it, so prohibiting it
creates a barrier to adoption for HTTP/2.0 which has no impact on
performance or the other parts of HTTP/2.

Making SPDY (or HTTP/2.) suport it, however, is relatively simple.  James'
proposal in this thread is getting close.  I'm a little worried about
demarcation of the two sets of headers, but the rest is straightforward.


> Cheers,
> --
> Mark Nottingham
> http://www.mnot.net/
Received on Tuesday, 7 August 2012 23:09:17 UTC

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