Re: HTTP/2 vs 1.1 semantics: intermediate codes

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.

On the server side, in particular with Servlet, it’s usually handled for you according to some configured policy. As an example, you can often set header restrictions (like content length), or authorization requirements and these are enforced immediately after receiving the headers. Additionally some impls will hold off the 100 until your first body read, actually allowing the servlet to reject early before the 100 is sent. Then there is also hooks where you can register specific custom handling code.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Thursday, 12 June 2014 20:11:43 UTC