Re: Getting to Consensus on 1xx Status Codes (#535)

Mark,

I don't see how my response is a separate issue?  You asked for a
preference between a) and b) and I gave it.

I'm fine with a), but see no point unless it supports 100.    I'm OK with
b), but see no point unless it deprecates 1xx for all http, not just h2

In short the WG should either support 1xx or not and that should apply
regardless of transport and I can live with anything that works towards
that.    Supporting it sometimes but not others is what I object to.









On 18 July 2014 10:42, Mark Nottingham <mnot@mnot.net> wrote:

> Greg,
>
> You're talking about a separable issue here; Julian's proposal is to
> maintain our current approach to 100 (Continue), and that has had very
> broad support within the WG.
>
> Cheers,
>
>
> On 17 Jul 2014, at 4:29 pm, Greg Wilkins <gregw@intalio.com> wrote:
>
> >
> > My preference is for 100 support.  Julian'd draft looks ok except that
> it excludes support for 100.   I'm fine with it excluding support for 101
> and 102.
> >
> > If 100 had been deprecated in rfc723x, then I'd would have lived with
> dropping it better, as I could have just dropped it entirely from the
> server and referred broken applications to the RFC.   But it is not
> deprecated for current h1 usage, so end points that will support both h1/h2
> will need to have 100 continue support anyway.  Making it dependent on the
> transport probably increases the complexity rather than decreases it.
> >
> > So I could live with b) if that document is targeted to both h1 and h2,
> so there is some prospect that we can drop support entirely in a few years.
> >
> > regards
> >
> >
> >
> >
> >
> >
> >
> >
> > On 17 July 2014 15:40, Mark Nottingham <mnot@mnot.net> wrote:
> > <https://github.com/http2/http2-spec/issues/535>
> >
> > So far, we've had two proposals for this issue;
> >
> > a) Accommodating non-final responses in HTTP/2
> >     See Julian's proposal at <
> https://gist.github.com/reschke/48ec30b0ac9d012b8b4e> for an idea of how
> this would look in the spec.
> >
> > b) Publishing a separate document deprecating 1xx status codes
> >     Thereby preventing the establishment of new ones (HTTP/2 already
> defines how to deal with 100, and 101 is not relevant to this protocol. 102
> was dropped by its primary use case, WebDAV, here: <
> http://tools.ietf.org/html/rfc4918#appendix-F.3>)
> >
> > I'd like to hear:
> >
> > 1) Your preferred outcome (if any)
> > 2) Whether you can live with the other option, and if not, why
> >
> > "I have no preference" is useful information too.
> >
> > If you indicate you can't live with one (or both) of the options, you
> MUST give a detailed, relevant reason as to why; omitting the reason means
> your "can't live with" will be ignored.
> >
> > Thanks,
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > Greg Wilkins <gregw@intalio.com>
> > http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> > http://www.webtide.com  advice and support for jetty and cometd.
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>


-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.