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

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

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 18 Jul 2014 10:54:19 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <9A85FE04-7969-4B19-BD7A-48B856A30557@mnot.net>
To: Greg Wilkins <gregw@intalio.com>

On 18 Jul 2014, at 10:52 am, Greg Wilkins <gregw@intalio.com> wrote:

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

OK, that's helpful. (b) is explicitly for all of HTTP, not just HTTP/2 -- hence, it's in a separate document.


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

--
Mark Nottingham   https://www.mnot.net/
Received on Friday, 18 July 2014 00:54:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC