- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 12 Jun 2014 22:51:48 +0200
- To: Jason Greene <jason.greene@redhat.com>
- CC: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 2014-06-12 22:11, Jason Greene wrote: > > On Jun 12, 2014, at 1:06 PM, Julian Reschke <julian.reschke@gmx.de> wrote: > >> On 2014-06-12 19:56, Jason Greene wrote: >>> >>> On Jun 12, 2014, at 12:12 PM, Julian Reschke <julian.reschke@gmx.de> wrote: >>> >>> -snip- >>> >>>> >>>>> In the 20+ years of HTTP, we've defined 3 1xx codes in total. >>>>> >>>>> Of those, >>>>> a. HTTP/2 provides a far superior alternative to 100 >>>>> b. HTTP/2 does not need 101. >>>>> c. 102 has been long deprecated. >>>>> >>>>> So while I can agree that the capability is interesting from a >>>>> theoretical standpoint, it's quite hard to justify spending effort on >>>>> a feature that is some combination of not needed, not wanted and not >>>>> used. >>>> >>>> Chicken-and-egg. APIs do not give access to 1xx codes, so nobody is using them right now. >>> >>> That’s not entirely accurate. Expect-100 is used by default with all MS .NET Web Services. It’s supported (although usually not on by default) by various Java frameworks as well. >> >> What I meant is that the 1xx are not exposed. Neither in the servlet API, nor in XHR (these are the APIs I care about). > > I think with XHR the expectation was that the browser is/should be in control of this. > > As to standalone client size, the JDK HttpUrlConnection lets you use expect 100, as well as a bunch of common client libraries like httpclient. And of course, MS WS clients. IIRC curl even sends Expect 100s on posts. I meant 1xx codes other that 100. > ... Best regards, Julian
Received on Thursday, 12 June 2014 20:52:26 UTC