Re: Some general SPDY feedback / questions

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.

Mike




>
> Cheers,
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>
>
>
>
>