Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

From: Kazuho Oku <[email-masked]>
Date: Tue, 1 Nov 2016 16:08:43 +0900

2016-11-01 15:32 GMT+09:00 Julian Reschke <[email-masked]>:
> On 2016-11-01 02:32, Kazuho Oku wrote:
>>
>> Cory, Julian, thank you for looking into the I-D.
>>
>> Thank you for looking into the existing implementations using Python.
>> Your research makes it evident that some kind of negotiation is
>> mandatory if we are going to use 103 on the public Internet.
>
>
> Having to negotiate it makes me sad.

Thank you for the suggestion.

I think having negotiation is a good thing for Early Data, since there
is no point in sending Early Data to a client that does not recognizes
the headers included in the informational response. So I'd expect that
if we define an Accept-EH header, a server serving to the Internet
will send Early Data only when the header has included in the request.

OTOH, we do not need to use Accept-EH header on a deployment in which
the peer is known to support Early Data.

Considering the two, having a clause like the following (with
non-normative text explaining the background) seems reasonable to me:

    “a server SHOULD NOT send Early Data unless the client has sent an
Accept-EH header”

Does this look fine to you?

>> For the purpose, defining an Accept-EH header (much like Accept-CH)
>> might make sense. For example, a client can send `Accept-EH: Link` to
>> indicate that it will recognize link headers within the Early Hints.
>
>
> Can't we use "Prefer"?
>
>> For HTTP/2, my tendency leans toward using HTTP headers rather than
>> having its own way of negotiation, considering the fact that the
>> information transferred using Early Hints could be considered
>> end-to-end rather than hop-by-hop, and also that we can expect HPACK
>> to compress Accept-EH header efficiently.
>
>
> For HTTP/2, I think we should push stronger to fix the code and not
> negotiate at all.
>
>>>
>>> I’ll start filing bugs against relevant repositories to address this
>>> behaviour so that the Python ecosystem is less embarrassingly unprepared for
>>> further 1XX status codes, but in the short-to-medium term it would be much
>>> better if we could negotiate the 103 status code rather than assume it will
>>> function correctly.
>>
>>
>> Fantastic! Thank you for all your efforts.
>
>
> Best regards, Julian
>

-- 
Kazuho Oku

---

From: Julian Reschke <[email-masked]>
Date: Tue, 1 Nov 2016 08:25:03 +0100

> Does this look fine to you?

I would avoid BCP14 keywords here. If a recipient fails because it has 
broken 1xx handling, I wouldn't want a statement like that support them 
in their view.

> ...

Best regards, Julian

---

From: Cory Benfield <[email-masked]>
Date: Tue, 1 Nov 2016 08:17:22 +0000

> On 1 Nov 2016, at 06:32, Julian Reschke <[email-masked]> wrote:
> 

I’m right there with you Julian. The 1XX response category gets to be another marker pointing us to the lesson the IETF has been learning for the past decade or so: extension points on a specification that no-one uses rust over time and become unusable.

In this case, I think the 1XX problem is more oversight than anything else. The problems in all these cases are tractable, and can be fairly easily fixed. It’s just that someone needs to spend that time.

> For HTTP/2, I think we should push stronger to fix the code and not negotiate at all.

So for HTTP/2 the state of play is different. There are far fewer implementations, and those that exist are better and more actively developed. I’m happy to say for h2 that we don’t require negotiation of the extension.

Cory

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Tue, 1 Nov 2016 21:18:52 +0900

On Mon, Oct 31, 2016 at 11:25 PM, Kazuho Oku <[email-masked]> wrote:

> Hi,
>
> I've just posted a new I-D named "An HTTP Status Code for Indicating
> Hints".
>
> The draft can be found at
> https://datatracker.ietf.org/doc/draft-kazuho-early-hints-status-code/
> A prettified editor's copy can be found at https://kazuho.github.io/
> early-hints/
>
> The draft proposes a new _informational_ status code that can be used
> for indicating hints to help a client start making preparations for
> processing the final response, while the server struggles to build the
> final response.
>
> Actually, we already have a working implementation. H2O, our HTTP/2
> server, recognizes Link: rel=preload headers within an informational
> response sent from upstream, and tries to push the specified resource.
> One reason I decided to write this draft is because I believe it would
> be better to standardize the mechanism.
>
> But I also believe that having support for this status code within the
> web browsers is beneficial as well.
>
> For example, the proposed status code can be used by edge servers to
> notify the client the existence of third-party resources while the
> request is processed by an upstream server. It can also be used as an
> alternative to H2 push on a bandwidth-constrained network.
>
> In short, I consider the proposed method as a good complement to H2 push.
>
> Please let me know what you think. Thank you in advance.
>
>
​Thank you for working on this.
Our nghttp2 nghttpx proxy has supported this feature since this April.  So
we have 2 proxy implementations already​.
​At the moment, I'm not aware of any application server/framework​ that
allows developers to send non-final response.
But if they are interested in this draft, and find it useful, things may
change rapidly.

​Best regards,
Tatsuhiro Tsujikawa​

> ---------- Forwarded message ----------
> From:  <[email-masked]>
> Date: 2016-10-31 23:09 GMT+09:00
> Subject: New Version Notification for
> draft-kazuho-early-hints-status-code-00.txt
> To: Kazuho Oku <[email-masked]>
>
>
>
> A new version of I-D, draft-kazuho-early-hints-status-code-00.txt
> has been successfully submitted by Kazuho Oku and posted to the
> IETF repository.
>
> Name:           draft-kazuho-early-hints-status-code
> Revision:       00
> Title:          An HTTP Status Code for Indicating Hints
> Document date:  2016-10-31
> Group:          Individual Submission
> Pages:          4
> URL:
> https://www.ietf.org/internet-drafts/draft-kazuho-early-
> hints-status-code-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-kazuho-early-hints-status-code/
> Htmlized:
> https://tools.ietf.org/html/draft-kazuho-early-hints-status-code-00
>
>
> Abstract:
>    This memo introduces an informational status code for HTTP that can
>    be used for indicating hints to help a client start making
>    preparations for processing the final response.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> --
> Kazuho Oku
>
>

---

From: Mike Bishop <[email-masked]>
Date: Tue, 1 Nov 2016 17:24:59 +0000

FWIW, our implementation should already ignore this response and process the final status code correctly.  If you have a public endpoint that returns a hint, we can all do a quick field test.

-----Original Message-----
From: Cory Benfield [mailto:[email-masked]] 
Sent: Tuesday, November 1, 2016 1:17 AM
To: Julian Reschke <[email-masked]>
Cc: Kazuho Oku <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

Cory

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 1 Nov 2016 20:58:59 +0100

Thanks Kazuho for putting forward this draft.

Apache httpd will on next release properly process, and forward unannounced 1xx responses until a final response arrives (read: it currently does not, shame on me). I plan to add support for converting 103 headers into PUSHes, but am unable to promise that for the next release. It may or may not happen. Interestingly, I might use 103 responses just internally in httpd to let the HTTP/1 parts trigger a push before starting processing the complete response.

Any 'Accept-EH' headers for proxying h1 connections are configurable via the usual directives. So that part is easily handled.

I plan to forward any 103 responses to the client, regardless if 103 triggered PUSHes or not. I sensed agreement here that we ask h2 implementations to just cope with that. 

The question I have in regard to timing: is there any requirement on PUSH_PROMISES to arrive before a 103 or can that one come first. (There was some sensibility in regard to final responses, so prefetches could adapt in time).

-Stefan
 
> Am 01.11.2016 um 18:24 schrieb Mike Bishop <[email-masked]>:
>

---

From: Cory Benfield <[email-masked]>
Date: Tue, 1 Nov 2016 22:08:06 +0000

> On 1 Nov 2016, at 17:24, Mike Bishop <[email-masked]> wrote:
> 

Were you interested in a HTTP/1.1 or HTTP/2 endpoint? I can put one up that unconditionally returns a 103, though it may just be easier to spin up H2O or nghttp2.

Cory

---

From: Mike Bishop <[email-masked]>
Date: Tue, 1 Nov 2016 22:22:05 +0000

Shouldn't matter, for us.  I'll defer to others.

-----Original Message-----
From: Cory Benfield [mailto:[email-masked]] 
Sent: Tuesday, November 1, 2016 3:08 PM
To: Mike Bishop <[email-masked]>
Cc: Julian Reschke <[email-masked]>; Kazuho Oku <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

Cory

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 1 Nov 2016 15:50:25 -0700

> On Nov 1, 2016, at 1:17 AM, Cory Benfield <[email-masked]> wrote:
> 
> 

No.  What I've learned is that every feature in every protocol is poorly
implemented by some poor soul who thinks they deserve special consideration
for their inability to interoperate with the future.  I have, in the past,
consistently refused such considerations.

> In this case, I think the 1XX problem is more oversight than anything else. The problems in all these cases are tractable, and can be fairly easily fixed. It’s just that someone needs to spend that…

They are easily fixed.  Force the broken implementations to die in a miserable
way and teach people not to write crappy code.

There is absolutely no reason to negotiate 1xx codes.  If some application fails
because their developers can't read, it is not our responsibility to work around them.
If we do anyway, the entire Internet goes to crap (just like it has for HTML).
At most, we use User-Agent or Server to flag non-compliant implementations and
work around only specific versions of known-to-be-deployed breakage.

....Roy

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 2 Nov 2016 11:40:30 +0900

> Were you interested in a HTTP/1.1 or HTTP/2 endpoint? I can put one up that unconditionally returns a 103, though it may just be easier to spin up H2O or nghttp2.

I would very much appreciate it if you or somebody else could setup a
server that returns 103 so that people could check.

I won't have time for doing that myself for a week or so, and at the
moment H2O is incapable for sending 103 (it only recognizes 103 sent
from upstream and converts it into H2 push).

-- 
Kazuho Oku

---

From: Cory Benfield <[email-masked]>
Date: Wed, 2 Nov 2016 09:59:53 +0000

> On 1 Nov 2016, at 22:50, Roy T. Fielding <[email-masked]> wrote:
> 

I don’t understand where you think anyone who wrote a broken implementation is asking for special consideration. The only HTTP implementation I fully wrote is a HTTP/2 implementation that can handle 1XX codes per the specification. I certainly don’t need the special consideration for libraries I maintain, because I’ll be shipping patches for them.

I am simply informing the IETF that the vast majority of widely deployed HTTP client libraries today will fail in the face of the 103 status code. Since I looked at Python I have gone back and looked at Ruby, Javascript, and Go, and the same remains true there. All of these languages have implementations that surface the 103 to the user and swallow the 200. So far curl and wget are the only widely-deployed non-browser implementations I have found that handle the 103 the way that RFC 7230 says they should. While we should praise those implementers, we should acknowledge that curl and wget are so widely deployed that they get bug reports for all the wacky edge cases in the way that the smaller implementations do not. (Yes, I called 1XX a wacky edge case, let’s all move on from it.)

> way and teach people not to write crappy code.

That fixes nothing. While I’m sure it’s emotionally satisfying to metaphorically slap developers around the face and scream “OBEY. THE. RFC” at them, the very existence of RFCs 7230+ is a good reminder that developers almost universally do not pay attention to the RFCs: they pay attention to the protocol *as encountered on the web*. That protocol has had for its entire lifetime only two 1XX status codes: 100 and 101. Protocol implementations almost universally handle those status codes correctly: just no others in the range. And that hasn’t mattered because no-one is *using* those other codes.

And so, we have come to use an extension point that was written into the protocol 17 years ago and never used, and we have found that it is rusty. This should not be a surprise to us. We should be equally wary of all the other unused extension points in the protocol (chunk extensions, anyone?), because all will trigger this similar failure mode.

Actually fixing this problem requires developer effort to write patches and to land them. I had already acknowledged this in the quote above: I was merely pointing out that we are locking the stable door after the horse has bolted. Thanks to the magic of long-term-support Linux releases the vast majority of deployed code today cannot handle the 103 status code, and that code will be with us for at least five years regardless of whether or not we patch the software.

All of this *excludes* the alarming reality of the many millions of embedded HTTP/1.1 stacks which are implementing a protocol that is at best a second cousin to the one specified in RFCs 7230+. The odds of those tolerating this response are pretty low: I’d be pretty impressed if you could find one.

> work around only specific versions of known-to-be-deployed breakage.

Well, firstly, let me note that all currently-specced 1XX status codes *are* negotiated. While 100 Continue is allowed to be sent without an “Expect” header requesting it, in practice it never is, so user-agents that don’t send the “Expect" header will never see it. Similarly, 101 is only sent in response to requests with an “Upgrade” header, so once again user-agents that never emit an “Upgrade: header will never see it. So while the spec sure as hell says that 1XX codes can be sent whenever, in practice they are only seen by user-agents that ask to see them.

Regardless, we can choose to flag non-compliant implementations. You’ll find, however, that the list of implementations is going to be pretty long. I have yet to bump into a HTTP implementation made available by a language standard library that handles 103 correctly, and most third-party implementations don’t either. That means the “known to be deployed” breakage basically includes almost every non-PHP web application deployed on the web today.

What that means is that the user-agent field will not be used to flag non-compliant implementations, it will be used to flag *compliant* ones, as there are vastly more of the former than the latter. That means that Chrome, Safari, Firefox, Opera (maybe), curl, and wget will all get a pass, and everyone else will be “guilty until proven innocent”. That means that we are rolling out a feature that is expressly a "browsers-only” feature if we deploy it in this way.

Let’s not pretend that the doors will be slowly opened as other implementations get their houses in order, because that’s not what will happen. What will happen, instead, is that the implementations that really are making a genuine effort to be of high quality but didn’t get around to this niche use-case yet because they’re somewhat less well-resourced than the others will be forever locked out of this feature, because there is no registry of “user-agents that support feature X” that can be updated. The only option they’ll have is to user-agent spoof, and I thought we were trying not to encourage that any more.

I like this 103 status code, and I want it to be as widely deployable as possible. It seems like the easiest way to do that *today*, without causing server administrators angst about whether they’ll break their clients, is to use a header field that flags support of the feature. It’s certainly not mandatory, but the cost of it is pretty damn low. In the meantime, for HTTP/2, where the implementations are generally newer and of higher quality at this time, we can safely avoid negotiation if that makes you happier.

Cory

(Vaguely relatedly, Roy, your assertion that these implementations fail because “their developers can’t read” is one of the most grossly petty things I’ve read on this mailing list. Most of the implementations I’ve tested are open-source implementations that are maintained by one-to-two developers, part time. It turns out that the real world of implementing HTTP/1.1 is sufficiently complex that writing code to support a feature that has been used literally zero times prior to this moment was not high up the priority list of implementers. So it’s not that they "can’t read", it’s that they prioritised their work items to actually solve the problems their users have, and “being served unexpected 1XX status codes” wasn’t on that list. Clearly all us independent implementers are amateur-hour hacks with no business being on the web.)

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 2 Nov 2016 21:11:51 +0900

> work around only specific versions of known-to-be-deployed breakage.

Thank you for your comments.

It is encouraging to see your comment that the effort to improve the
web should not be obstructed by the existence of broken
implementations.

OTOH, for 103 Early Data, I think sending a request header that
indicates that the client is going to recognize the headers contained
in the informational response might be beneficial.

For example, a client that recognizes link: rel=preload in 103 could
send an "Accept-EH: Link" header to notify the server that it's
operation would be optimized by the use of 103.

For clients that do not recognize any of the headers sent using 103,
there'd be no reason to send an informational response. Sending one is
just waste of bandwidth. So a server can just omit the 103 response to
clients that do not send an Accept-EH header.

I also think that we should have a warning that sending 103 against
arbitrary HTTP clients may cause interoperability issues, but I now
agree to Julian that it shouldn't be normative (i.e. not use the terms
defined in RFC2119).

-- 
Kazuho Oku

---

From: Patrick McManus <[email-masked]>
Date: Wed, 2 Nov 2016 11:16:32 -0400

[co-chair hat on]

On Wed, Nov 2, 2016 at 5:59 AM, Cory Benfield <[email-masked]> wrote:

> I don’t understand where you think anyone who wrote a broken
> implementation is asking for special consideration. The only HTTP
> implementation I fully wrote is a HTTP/2 implementation that can handle 1XX
> codes per the specification. I certainly don’t need the special
> consideration for libraries I maintain, because I’ll be shipping patches
> for them.
>
> I am simply informing the IETF that the vast majority of widely deployed
> HTTP client libraries today will fail in the face of the 103 status code.
> Since I looked at Python I have gone back and looked at Ruby, Javascript,
> and Go, and the same remains true there.

This is a normal and potentially helpful tension. Cory has done some
research involving running code that helps influence this discussion. The
IETF values running code - thanks for the data and your implementations.
Certainly interop is a valid consideration.

Roy is pushing back more or less with an ossification argument - we can't
be afraid to use features that are well defined. That's also a valid
consideration - thanks for the point Roy.

Balancing this is the soup of early draft rough consensus, right? (Please
note that this isn't currently a WG draft - but its certainly on topic to
discuss as long as it doesn't drown out our adopted work.)

I'm sure we can all keep it within the bounds of the normal professionalism
this list typically exhibits.

> What that means is that the user-agent field will not be used to flag
> non-compliant implementations, it will be used to flag *compliant* ones, as
> there are vastly more of the former than the latter. That means that
> Chrome, Safari, Firefox, Opera (maybe), curl, and wget will all get a pass,
> and everyone else will be “guilty until proven innocent”. That means that
> we are rolling out a feature that is expressly a "browsers-only” feature if
> we deploy it in this way.
>
>
I'd like to hear more opinions on this general topic - abstracted away from
103 if we can. UA and Server of course were aimed at the
whitelist/blacklist idea but in reality, at least from my pov, lead to a
pretty terribly ossified world - full of sniffing and masquerading and out
of date lists. Explicit negotiations have, at least recently, developed a
better track record.. and with h2's more efficient heading encoding seem to
be a better practice (again from my pov).

---

From: Werner Baumann <[email-masked]>
Date: Wed, 2 Nov 2016 16:53:59 +0100

Am Wed, 2 Nov 2016 09:59:53 +0000
schrieb Cory Benfield <[email-masked]>:
> (Vaguely relatedly, Roy, your assertion that these implementations
> fail because “their developers can’t read” is one of the most grossly
> petty things I’ve read on this mailing list. Most of the
> implementations I’ve tested are open-source implementations that are
> maintained by one-to-two developers, part time. It turns out that the
> real world of implementing HTTP/1.1 is sufficiently complex that
> writing code to support a feature that has been used literally zero
> times prior to this moment was not high up the priority list of
> implementers. So it’s not that they "can’t read", it’s that they
> prioritised their work items to actually solve the problems their
> users have, and “being served unexpected 1XX status codes” wasn’t on
> that list. Clearly all us independent implementers are amateur-hour
> hacks with no business being on the web.)
> 
I am the only developer of a WebDAV-client (davfs2) and I did read the
spec.
My project makes use of the Neon library, developed by a single person
who did read the spec.
I don't spend a lot of time reading the specs. I spend a lot of time
writing workarounds for servers, who's implementers did not read the
spec. And a great deal of user support is about buggy servers that
conflict with the spec in an obvious way.

> Well, firstly, let me note that all currently-specced 1XX status codes
> *are* negotiated. While 100 Continue is allowed to be sent without an
> “Expect” header requesting it, in practice it never is, so user-agents
> that don’t send the “Expect" header will never see it. 

This needs a lot of twisting the word negotiation.
If I never send a valid GET-request I will never see a 200-response
with a resource in the body. So when sending a valid GET-request I
negotiate 200 OK?

The Expect-100 header does not tell the server that the client is able
and willing to handle 100 Continue responses. It tells the server that
the client will not send the body until it gets the OK from the server.
Using a protocol feature is not negotiating it.

Your argument sounds as if the preferred way to implement a protocol is
to revers engineer the protocol from what you see on the wire.

---

From: Cory Benfield <[email-masked]>
Date: Wed, 2 Nov 2016 16:50:14 +0000

> On 2 Nov 2016, at 15:53, Werner Baumann <[email-masked]> wrote:
> 

So your assertion is that…I didn’t read the specs? I can’t really parse this as anything other than you agreeing with the assertion that anyone who has written code that deviates from specification is an amateur-hour hack. That’s a little bit tricky for me to countenance, frankly. Mistakes, bugs, and deviations from specifications aren’t just common, they are the norm, and the less-common the specification feature is the more likely that there will be non-compliance. If it’s the case that both you and the Neon developers wrote your implementation completely to specification before you released it then frankly you are the exception, not the rule.

> Using a protocol feature is not negotiating it.

The sentence you’re quoting covers this. Specifically, I said (emphasis added by me for clarity): “while 100 Continue is allowed to be sent without an “Expect” header requesting it, *in practice it never is*”. This means that regardless of the fact that the protocol feature can be used spontaneously by servers, it isn’t. This is effectively equivalent to negotiation. If servers emitted 100 Continue in response to all POST/PUT requests I’d feel differently, but they don’t.

So while the specification doesn’t say that the Expect header doesn’t tell the server that the client is able to handle 100 responses, in practice that’s exactly how servers read it.

> to revers engineer the protocol from what you see on the wire.

I said no such thing, but regardless, this specific conversational thread is off topic for this list.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 2 Nov 2016 18:16:34 +0000

Patrick, thank you for helping to maintain balance here.  An aside:  My favorite anti-ossification UA-sniffing encounter is this one:  “Edge, could you please stop claiming to be that particular version of Chrome?  That version of Chrome had a bug and we sent different HTML to work around it, but you don’t have that bug and can handle the normal content.  So now I have to special-case your lie out of the special-case for Chrome.”

I’m personally a fan of “follow the spec and let broken code fall where it may.”  And professionally, I spend a lot of my day discussing how not to make the broken code freak out when we fix a bug.  So I understand the tension very well.  While I agree with Roy that probably the first thing that should have been implemented in any given library is “unknown NXX is treated as N00, make sure I have a processing path for N00,” N=1 is a rare case that could easily have been skipped in a pragmatic implementation.

I’m in favor of the same flow that currently happens for 100 – clients can indicate when they think it would be useful, servers MAY send unsolicited, but with a compat warning that likely will keep them from actually doing so without the hint.  And maybe we should note for a future HTTP/1.1 update that this should be made an explicit pattern for 1XX codes, since it’s become the de facto norm.

From: Patrick McManus [mailto:[email-masked]]
Sent: Wednesday, November 2, 2016 8:17 AM
To: Cory Benfield <[email-masked]>
Cc: Roy T. Fielding <[email-masked]>; Julian Reschke <[email-masked]>; Kazuho Oku <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

[co-chair hat on]

On Wed, Nov 2, 2016 at 5:59 AM, Cory Benfield <[email-masked]<mailto:[email-masked]>> wrote:

> On 1 Nov 2016, at 22:50, Roy T. Fielding <[email-masked]<mailto:[email-masked]>> wrote:

I am simply informing the IETF that the vast majority of widely deployed HTTP client libraries today will fail in the face of the 103 status code. Since I looked at Python I have gone back and looked at Ruby, Javascript, and Go, and the same remains true there.

This is a normal and potentially helpful tension. Cory has done some research involving running code that helps influence this discussion. The IETF values running code - thanks for the data and your implementations. Certainly interop is a valid consideration.
Roy is pushing back more or less with an ossification argument - we can't be afraid to use features that are well defined. That's also a valid consideration - thanks for the point Roy.
Balancing this is the soup of early draft rough consensus, right? (Please note that this isn't currently a WG draft - but its certainly on topic to discuss as long as it doesn't drown out our adopted work.)
I'm sure we can all keep it within the bounds of the normal professionalism this list typically exhibits.

I'd like to hear more opinions on this general topic - abstracted away from 103 if we can. UA and Server of course were aimed at the whitelist/blacklist idea but in reality, at least from my pov, lead to a pretty terribly ossified world - full of sniffing and masquerading and out of date lists. Explicit negotiations have, at least recently, developed a better track record.. and with h2's more efficient heading encoding seem to be a better practice (again from my pov).

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 2 Nov 2016 15:50:02 -0700

> On Nov 2, 2016, at 2:59 AM, Cory Benfield <[email-masked]> wrote:
> 
> 

Sorry, I was talking about the past.  You made a general comment about the
nature of protocol extensibility mechanisms based on the evidence of existing
implementations having bugs.  But existing implementations have bugs for every
aspect of the protocol, for the same reason: some developers don't read
specifications.  The only distinction here is how long it takes for someone
to get around to testing a use case which triggers the bug and results in
a bug report which can then be fixed by some developer.

> I am simply informing the IETF that the vast majority of widely deployed HTTP client libraries today will fail in the face of the 103 status code. Since I looked at Python I have gone back and look…

Thanks for the information.  FTR, 100 and 101 were originally defined.
102 was an extension.  There have been several attempts to define a 103
for various reasons, but they were deemed close enough to 102 that they
were not worth pursuing further.  There are also many uses of 1xx status
codes within non-standard systems for which no registration was necessary,
mostly for the sake of hinting at optional features or local status.

> That fixes nothing. While I’m sure it’s emotionally satisfying to metaphorically slap developers around the face and scream “OBEY. THE. RFC” at them, the very existence of RFCs 7230+ is a good remi…

Please don't lecture me on the nature of HTTP deployment.  You are aware of
maybe 5% of deployed implementations.  I get regular questions from a much
broader scope, because my name is on the specs. Your premise is mistaken,
and the lesson you took from it is simply wrong.

In my experience, most developers (especially open source developers like me)
are happy to fix bugs in their software, particularly when they are backed
by specification text that is now 21 years old (and still counting).

I don't care how widely they are deployed.  Not a single client on your
list existed when 1xx was invented.  Not a single one will still exist
(in any meaningful sense) more than ten years from now.  They are broken
in terms of the protocol usage, today, regardless of how Kazuho chooses
to negotiate the feature.  Adding another 10 or so bytes to every request
is not going to make them any less broken.

Let them surface the 103.  Force the bug to be fixed.  Encourage people to
upgrade their software.  That is far less expensive than sending extra bytes
on every request for the next 40 years.

....Roy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 3 Nov 2016 08:01:28 +0100

> by specification text that is now 21 years old (and still counting).

Agreed. When I first noticed haproxy was not properly handling 1xx, I fixed
it and redeployed. The only thing (especially with intermediaries) is that
these components are rarely upgraded, so the ones facing bugs are replaced
and the ones without bugs stay in place for 5+ years. But the good thing is
that when something new breaks your old deployment, you quickly notice it,
realize you're running an outdated, unsupported version, upgrade to the next
one and notice it fixes your problem for free.

So yes, adding new 1xx status codes will definitely break existing bogus
code, and by the time their users notice, fixes will be available and the
issue will only last for the time it takes to update the package.

Willy

---

From: Cory Benfield <[email-masked]>
Date: Thu, 3 Nov 2016 09:08:02 +0000

> On 2 Nov 2016, at 22:50, Roy T. Fielding <[email-masked]> wrote:
> 

Sure. But my comment was about having *well-oiled* extension mechanisms. Put another way, if you have exactly one place to put an extension, then that is where all extensions will be put. This will greatly increase the speed which with the bug-finding use-case will get tested, and the bug will get fixed. This was my point about 103: while we have had the 1XX extension point since 1996, we haven’t *used* it since 1999. It is hardly a surprise, then, that a number of implementations have bugs in their support of this little-used aspect of the protocol.

This is why I have been getting up in arms about the reaction to my statement. I didn’t say we can’t ship 103 with no negotiation, or that implementations shouldn’t fix their 103 handling. Of course we can, and of course they should. Hell, I’m still reporting bugs and patching them for 103 across the Python ecosystem, and I’ve reported bugs in non-Python implementations as well. What I was getting at is that we have a problem regarding the shipping of those bugfixes, which I’ll address more below.

> and the lesson you took from it is simply wrong.

Fair enough. I have no doubt you’re better informed on this topic than I am. All I know is that from where I am standing I see a vast sea of non-compliance and have never seen a non-100 or 101 status code, in any form. I drew my position from the evidence I had on hand.

> by specification text that is now 21 years old (and still counting).

Sure. And, as noted above, I didn’t say no-one was going to fix those bugs. I said that those fixes solve the problem we have in the future, but they don’t solve the problem we have today. Again, more on this below.

> is not going to make them any less broken.

To look at your age argument for a moment, yes they did. Python’s httplib was on my list, and I just downloaded Python 1.1, which was released in October 1994: httplib is present in that distribution as a HTTP/1.0 client implementation. (Not a very good one, I should note, but present nonetheless, and built off of draft-ietf-iiir-http-00 no less). Python’s httplib almost certainly *will* exist ten years from now because it is shipped with RHEL 7, which does not leave active support until 2024. So not only will httplib exist in 2024 but it will exist in the exact form it does today: no 103 fix present.

> on every request for the next 40 years.

But regardless of all of the above, this is the crux of the issue. Yes, we can choose to say “if you don’t tolerate 103 then bad luck, fix your software”. And either 103 will fail to be adopted, or people will fix their software. The problem isn’t “will people fix their software”: of course they will. The problem is how long will it take, and what effect will that have on the usage of the 103 status code.

Today I am working on patches for all the non-httplib implementations in the Python ecosystem. In the case of Twisted, that patch will be released no earlier than Twisted 17.1. That’s moderately problematic, as every released distribution of Red Hat Enterprise Linux today ships Twisted 8.2 or Twisted 12.1. Optimistically, RHEL 8 *might* get Twisted 17.1, but it also might not. If it does, RHEL 7 will stop being supported in 2024, which means that the last supported version of Twisted that doesn’t handle 103 will die in 2024.

The same problem exists for all other deployed versions of Python or Python software: if it is shipped with a distribution like Red Hat then it’s going to take a decade to get that version out of support. For Python 2.7’s httplib, which will not be unsupported by the Python team until 2020, there is no path to landing a patch for 103 support or even 1XX tolerance. Every shipped version of Python 2.7 will forever be unable to tolerate 103 responses.

What I am getting at here is that “encourage people to upgrade their software” is not a winner. I experience this fight every day as someone who ships open source software, and so far my hit rate is 0.000. People are unwilling to upgrade their software, even in the face of quite substantial feature or functionality deficits.

Anyway, I’m not really interested in this discussion beyond this point. The HTTP WG can do whatever it likes within the bounds of what is already specified, and it can choose to decide that these implementations have made their own bed and now must lie in it. But ultimately the burden of this breakage doesn’t fall on the person who wrote the code: it falls on the user who finds themselves unable or unwilling to upgrade. And it seems to me that we’d be punishing the wrong person.

Cory

---

From: Andy Green <[email-masked]>
Date: Thu, 03 Nov 2016 18:31:52 +0800

On Thu, 2016-11-03 at 09:08 +0000, Cory Benfield wrote:
> Sure. But my comment was about having *well-oiled* extension
> mechanisms. Put another way, if you have exactly one place to put an
> extension, then that is where all extensions will be put. This will 

Just jumping in with my tiny bit of experience on this narrow subject
of handwaving standardized extensions.

>From the point of view of ws, extensions were an almost complete
failure and came into being to stop the endless dithering (let us
recall, there were like 80 versions of that standard...) at least in
part caused by Google trying to mutate it into spdy.  It only got out
the door by the sleight of hand of pushing compression and mux into
"extensions" to be discussed later.  Ws mux was stillborn, because
Google passed on the honour and it instead became http/2.

So one of the two major targets for "ws extensions" said "nope", and
the only ws extension in any kind of actual use AFAIK is RFC7692
permessage-deflate.  Doing even that properly (ie, streaming the
deflate in chunks, rather than allocating for inflate of the whole
message) has radical impacts on the whole architecture, and supporting
generic extensions even more so --->

> greatly increase the speed which with the bug-finding use-case will

...therefore many ws implementations support neither extensions in
general nor permessage-deflate specifically.  (You might say, "that's
OK because they are extensions", but they architecturally decided they
repudiated the whole idea of extensions).  So no, it didn't increase
any bug finding.

>From this experience, I think maybe the standards should avoid looking
towards Founding An Empire That Lasts A Thousands Years and just have
it do what it should do.  If you look at http, his "extensions" were
very natural compared to ws reserved bits that will never come into
use, unused extensions bar one, you could just get additional random
headers with a well-defined way to skip what you didn't understand at
the per-header level.  The paleo-headers were "extensible", they were
not "extensions".  Or .well-known, as another example of a positive
pattern,  that didn't extend http at all but is open-ended for what it
does.

I want to suggest "extensions" are a sign the definition of the
protocol has failed...

-Andy

---

From: Werner Baumann <[email-masked]>
Date: Thu, 3 Nov 2016 11:42:50 +0100

Am Thu, 3 Nov 2016 09:08:02 +0000
schrieb Cory Benfield <[email-masked]>:

> > I don't care how widely they are deployed.  Not a single client on
> > your list existed when 1xx was invented.
> 
> To look at your age argument for a moment, yes they did. Python’s
> httplib was on my list, and I just downloaded Python 1.1, which was
> released in October 1994: httplib is present in that distribution as
> a HTTP/1.0 client implementation.
> 

From RFC 7231:

> 6.2 Informational 1xx
> ... Since HTTP/1.0 did not define any 1xx status codes, a server MUST
> NOT send a 1xx response to an HTTP/1.0 client.

Question:
For what kind of HTTP clients are these non conforming libraries used?
To what kind of HTTP servers do they connect? Is any of these servers
expected to start sending 103 responses? I would expect that at least
none of that IoT devices will ever have to deal with 103.

---

From: Cory Benfield <[email-masked]>
Date: Thu, 3 Nov 2016 10:50:43 +0000

> On 3 Nov 2016, at 10:42, Werner Baumann <[email-masked]> wrote:
> 

This is not relevant. httplib has been a HTTP/1.1 client for more than a decade. The age of httplib was relevant only because Roy suggested that httplib did not exist when 1xx was invented: this is my counter-example.

> none of that IoT devices will ever have to deal with 103.

Lots of them. In particular, they are frequently used for web scrapers, which will inevitably have to contend with 103 responses.

Cory

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 4 Nov 2016 00:31:59 +0900

Hi,

On Wed, Nov 2, 2016 at 11:40 AM, Kazuho Oku <[email-masked]> wrote:

> >> FWIW, our implementation should already ignore this response and
> process the final status code correctly.  If you have a public endpoint
> that returns a hint, we can all do a quick field test.
> >
> > Were you interested in a HTTP/1.1 or HTTP/2 endpoint? I can put one up
> that unconditionally returns a 103, though it may just be easier to spin up
> H2O or nghttp2.
>
​Meanwhile, I took my liberty, and setup h1 and h2 endpoint​ for 103 with
link rel=preload.
Access https://nghttp2.org/?103-eh and you will get 103, and then 200 final
status code.
There is no negotiation at the moment.

Best regards,
Tatsuhiro Tsujikawa

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 3 Nov 2016 18:29:30 +0100

> Am 03.11.2016 um 16:31 schrieb Tatsuhiro Tsujikawa <[email-masked]>:
> 
> [...]
> ​Meanwhile, I took my liberty, and setup h1 and h2 endpoint​ for 103 with link rel=preload.
> Access https://nghttp2.org/?103-eh and you will get 103, and then 200 final status code.

Thanks, Tatsuhiro. Helped me find a kink in Apache implementation.

-Stefan

---

From: Mike Bishop <[email-masked]>
Date: Thu, 3 Nov 2016 17:26:20 +0000

Great – looks like our stack handles it properly, but our developer tools don’t.  (Shows 103 and the Link: header as the response from the server; the 200 and its headers are nowhere to be found.)  I’ve filed a bug.

From: Tatsuhiro Tsujikawa [mailto:[email-masked]]
Sent: Thursday, November 3, 2016 8:32 AM
To: Kazuho Oku <[email-masked]>
Cc: Cory Benfield <[email-masked]>; Mike Bishop <[email-masked]>; Julian Reschke <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

Hi,

On Wed, Nov 2, 2016 at 11:40 AM, Kazuho Oku <[email-masked]<mailto:[email-masked]>> wrote:
2016-11-02 7:08 GMT+09:00 Cory Benfield <[email-masked]<mailto:[email-masked]>>:
>
>> On 1 Nov 2016, at 17:24, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
>>

Best regards,
Tatsuhiro Tsujikawa

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 3 Nov 2016 12:41:25 -0700

> mostly for the sake of hinting at optional features or local status.

Speaking of which, I did a search and found

   https://lists.w3.org/Archives/Public/ietf-http-wg/2008AprJun/0082.html

based on the use of 103 for Google Gears resumable HTTP file uploader
proposal (now lost in the bit vortex that was google code).

I think it is safe to reuse 103 (since we already reused 308), but just
something to keep in mind.  Or, feel free to skip to 104.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 Nov 2016 18:40:54 +1100

[ personal response ]

Hey Kazuho,

Interesting stuff, looks good to me. People have been asking for a facility to delay the status code for a while, but it's never happened, because that would require arbitrary buffering by clients (shifting it from the server). This is a nice compromise, at least for some use cases.

Saying that the headers are going to also appear in the final response nicely sidesteps the question of how to combine the two, while taking advantage of HPACK.

In retrospect, it's a bit of a shame that we have this requirement in H2: "All pseudo-header fields MUST appear in the header block before regular header fields." If not for that, we could send an "early" HEADERS followed by the :status etc. in a CONTINUATION.

I suppose a SETTING could be used to turn that requirement off, but I'm not sure that's more workable than just using a new status code, as you've done.

Cheers,

P.S. In the first paragraph of section 2, s/request/response/

> On 1 Nov. 2016, at 1:25 am, Kazuho Oku <[email-masked]> wrote:
> 
> Hi,
> 
> I've just posted a new I-D named "An HTTP Status Code for Indicating Hints".
> 
> A prettified editor's copy can be found at https://kazuho.github.io/early-hints/
> 
> https://www.ietf.org/internet-drafts/draft-kazuho-early-hints-status-code-00.txt
> Status:
> Please note that it may take a couple of minutes from the time of submission

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Nov 2016 20:03:20 +1100

> In retrospect, it's a bit of a shame that we have this requirement in H2: "All pseudo-header fields MUST appear in the header block before regular header fields." If not for that, we could send an…

I don't think that this is a problem.  I mean, for requests it means
that routing based on the URL can happen without arbitrary buffering.
That we also did it for responses is perhaps unnecessary, but it's a
little bit of certainty and opening the door for progressive
generation of headers also opens the door to new classes of ambiguity
as well.  Especially since we still allow individual header fields to
come in piecemeal.  I think that I prefer Kazuho's approach.

The progressive response means that this is OK for progressive things.
I wouldn't want to see a server change its mind about something;
content-type might be hazardous, for example.

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 7 Nov 2016 17:55:23 +0900

> In retrospect, it's a bit of a shame that we have this requirement in H2: "All pseudo-header fields MUST appear in the header block before regular header fields." If not for that, we could send an…

Thank you for your comment.

Using CONTINUATION to split hints and actual headers sounds like an
interesting idea.

However, I am worried about the limits of the approach, due to the
fact that you cannot send any information related to a different
stream within a set of HEADERS frame and the following CONTINUATION
frames.

For example, you'd might want to send links of external resources
along with H2 pushes of resources belonging to the same origin. Such
combination is possible only by using an informational response.

> P.S. In the first paragraph of section 2, s/request/response/

Thank you for pointing that out. Fixed in my draft.

-- 
Kazuho Oku

---

From: Mike Bishop <[email-masked]>
Date: Mon, 7 Nov 2016 18:15:11 +0000

Compare to including differing headers between a 200 and a 304, for example -- the RFC says that servers SHOULD NOT emit headers that change the interpretation of the cached content, but that clients MUST merge in any headers the server chooses to emit.  But in practice, every browser has a list of headers it won't let the server change its mind about, and will ignore the server if it tries.  Allowing contradictory information here runs into the same effective problem.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Monday, November 7, 2016 1:03 AM
To: Mark Nottingham <[email-masked]>
Cc: Kazuho Oku <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: New Version Notification for draft-kazuho-early-hints-status-code-00.txt

> In retrospect, it's a bit of a shame that we have this requirement in H2: "All pseudo-header fields MUST appear in the header block before regular header fields." If not for that, we could send an…

I don't think that this is a problem.  I mean, for requests it means that routing based on the URL can happen without arbitrary buffering.
That we also did it for responses is perhaps unnecessary, but it's a little bit of certainty and opening the door for progressive generation of headers also opens the door to new classes of ambiguity as well.  Especially since we still allow individual header fields to come in piecemeal.  I think that I prefer Kazuho's approach.

The progressive response means that this is OK for progressive things.
I wouldn't want to see a server change its mind about something; content-type might be hazardous, for example.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Nov 2016 16:58:33 +1100

I think if we focus on the "hints" part of the 1xx's semantics, it helps clarify those decisions. I.e., nothing you get in that message is something you can depend upon when interpreting the final response; it's just information you can use for optimisation.

> On 8 Nov. 2016, at 5:15 am, Mike Bishop <[email-masked]> wrote:
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 8 Nov 2016 15:21:22 +0100

On 2016-10-31 19:21, Cory Benfield wrote:
> ...
> While I’m here, I’d like to discuss section 3. To provide some data points, most of the HTTP/1.1 clients in the Python ecosystem will not handle a new 1XX status code very well. A quick survey of the ecosystem suggests that the following tools will all misbehave:
>
> - every standard library http client (urllib, urllib2, httplib), all of which treat only “100 Continue” specially: the rest will treat the 103 header block as the final response and, because it MUST NOT have a content-length, will read until connection close.
> - every third-party library built on top of those tools, including urllib3, Requests, and httplib2, which inherit their misbehaviour.
> - aiohttp, which special-cases 100 and 101 but not any others
> - Twisted’s client, which special-cases 100
> ...

FWIW,

I just did a small Java test with a) JDK's URLConnection and b) Apache 
HTTP client 4.5.x.

a) Works in that it returns the correct response, but only after waiting 
for a timeout to occur it seems (needs to be investigated)

b) Works properly.

Neither API exposes the intermediate status, but at least for b) it 
looks like a relatively simple change.

-- snip --
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.URL;

import org.apache.http.HttpException;
import org.apache.http.HttpResponse;
import org.apache.http.HttpResponseInterceptor;
import org.apache.http.client.HttpClient;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.HttpClientBuilder;
import org.apache.http.protocol.HttpContext;
import org.apache.http.util.EntityUtils;

public class Test103 {

     public static void main(String[] args) throws IOException {
         apache();
         java();
     }

     private static void apache() throws IOException {
         HttpClient c = HttpClientBuilder.create().build();
         HttpGet get = new HttpGet("https://nghttp2.org/?103-eh");
         HttpResponse resp = c.execute(get);
         System.out.println(resp.getStatusLine());
         System.out.println(EntityUtils.toString(resp.getEntity()));
     }

     private static void java() throws IOException {
         URL test = new URL("https://nghttp2.org/?103-eh");
         InputStream is = test.openConnection().getInputStream();
         byte[] bytes = readFully(is);
         System.out.println(new String(bytes));
     }

     public static byte[] readFully(InputStream is) throws IOException {
         ByteArrayOutputStream buffer = new ByteArrayOutputStream();
         int nRead;
         byte[] data = new byte[16384];

         while ((nRead = is.read(data, 0, data.length)) != -1) {
             buffer.write(data, 0, nRead);
         }

         buffer.flush();

         return buffer.toByteArray();
     }
}
-- snip --

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 8 Nov 2016 18:24:09 +0100

> for a timeout to occur it seems (needs to be investigated)

Actually, it's broken. It takes the 103 as final message and then wait's 
for a timeout, then returns everything starting with "HTTP/1.1 200 OK" 
as response body.

(Will file a bug soonish)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 11 Nov 2016 08:49:42 +0100

> (Will file a bug soonish)

Test case attached. Will let you know once the bug appears in the issue 
tracker.

Q: maybe we should create a Wiki page, summarizing implementation status 
and bug reports?

Best regards, Julian

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 11 Nov 2016 17:00:26 -0700

> Q: maybe we should create a Wiki page, summarizing implementation status

FWIW, based on the results I had access to, most of the HTTP proxies
using our HTTP compliance test suite mishandled 1xx messages one way or
the other. Even today, after all the tests and bug fixes, there is an
outstanding Squid bug where an unfortunate timing of 1xx and other
events lead to a crash. 1xx is evidently tricky to get right.

This data point is not meant to support or combat the "let the bad
implementations surface/suffer" argument. I am just reporting that many,
possibly most proxies mishandle 1xx messages.

HTH,

Alex.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 12 Nov 2016 08:33:47 +0100

> possibly most proxies mishandle 1xx messages.

Thanks for the feedback.

When you talk about "timing", does that apply to any 1xx, or just the 
100-continue dance?

Best regards, Julian

---

From: Alex Rousskov <[email-masked]>
Date: Sat, 12 Nov 2016 08:55:13 -0700

> When you talk about "timing", does that apply to any 1xx, or just the

The bugs depend on the proxy, naturally. Some do not forward any 1xx,
some forward only 100 (Continue), some mistake 1xx for the final
response, some cannot handle an early final response received in the
same TCP packet as 1xx, etc. etc.

The specific Squid bug I used as a recent example applies to all 1xx
control messages and their timing relative to other rare events such as
client or server disconnect or timeout. Thus, it is not specific to
100-continue. Statistically speaking, releasing more 1xx events into the
wild will expose more 1xx implementation bugs.

Alex.

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 13 Nov 2016 21:36:27 +0900

> possibly most proxies mishandle 1xx messages.

Thank you for the info.

I do not have a strong preference on whether if we should try to
rescue the broken implementations, but to me your report is
interesting in the fact that it shows the bounds of using header-based
negotiation to work-around such implementations.

HTTP headers are end-to-end by default. Therefore a request header for
negotiating the use of 103 would go through an intermediary incapable
of handling 1xx correctly. We might consider designating the header
used for negotiation as a hop-by-hop header, but I'd be scared of
using a new token to the connection header (for interoperability
issues).

In other words, using header-based negotiation for Early Hints only
limitedly improves interoperability.

PS. sorry if my response resumes the combat.

-- 
Kazuho Oku

---

From: Kari Hurtta <[email-masked]>
Date: Sun, 13 Nov 2016 18:40:43 +0200 (EET)

> using a new token to the connection header (for interoperability

It is also possible to Connection: -header implementation is broken.

So if 1xx is broken, it does not help use Connection: for to
indicate hop-by-hop header if this is not honored either.

Seems likely that both little used featured are broken
on same implementation.

/ Kari Hurtta

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Nov 2016 05:48:50 +0100

> limitedly improves interoperability.

...but then, requiring HTTPS (in theory eliminating broken middle boxes) 
would, right?

Best regards, Julian

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 14 Nov 2016 14:56:44 +0900

> ...but then, requiring HTTPS (in theory eliminating broken middle boxes)

Yes.

However, I would expect that in many (if not most) cases a web
application server running behind of a reverse proxy (or a CDN edge
server) to generate 103 response.

In such deployment, TLS gets terminated by the reverse proxy. So even
if a client and an application server negotiated the use of 103, we
would see issues if the reverse proxy between the two was broken.

So to me, it seems like that the conservative approach would be to
only send 103 over HTTP/2 or to a peer that is known to handle it
correctly (e.g. CDN edge server converting 103 LRP to H2 push).

-- 
Kazuho Oku

---

From: Cory Benfield <[email-masked]>
Date: Mon, 14 Nov 2016 09:14:47 +0000

> On 13 Nov 2016, at 16:40, Kari Hurtta <[email-masked]> wrote:
> 

I suspect Kari and Kazuho are right here: it is likely that any implementation that mishandles 1XX responses will also mishandle the Connection header. My experience of working with implementations and implementers is that the Connection field is extremely poorly understood.

This is unfortunate. I was advocating for the header-based negotiation because I believed that the state of affairs for intermediaries was likely to be better than it is for the long-tail of OSS client implementations, but it looks like it isn’t. With that in mind then, I think we have three options:

1. As Julian suggested, restrict use of this response to HTTPS only and then negotiate via header field. This doesn’t necessarily solve the problem (HTTPS may be used to an intermediary), and also preferences the needs of clients over intermediaries. I’m not sure that’s a good plan.

2. As Kazuho has suggested, restrict use of the status code to H2 where implementations generally-speaking handle the less-used spec features better.

3. Don’t put any spec limitations on the use of the status code and allow implementers to decide under what conditions they are willing to emit the header field.

For my part, I think either 2 or 3 is the best solution. I don’t see any reason to want to do an end-run around intermediaries like in (1). I’m open to (3). I think in practice we will see limited update in HTTP/1.1 for a while, but that may have to just be ok.

Cory

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 14 Nov 2016 18:44:00 +0900

> For my part, I think either 2 or 3 is the best solution. I don’t see any reason to want to do an end-run around intermediaries like in (1). I’m open to (3). I think in practice we will see limited…

Thank you for laying down the options.

My preference is 3, with possibly some warnings using non-normative
form alerting the reader that there might be interoperability issues
especially when HTTP/1 is used.

-- 
Kazuho Oku

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 14 Nov 2016 11:13:48 +0100

> Am 14.11.2016 um 10:44 schrieb Kazuho Oku <[email-masked]>:
> 

+1

>> Cory

Stefan