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

Re: HTTP/2 vs 1.1 semantics: intermediate codes

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 12 Jun 2014 22:51:48 +0200
Message-ID: <539A12E4.1050300@gmx.de>
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

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