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

[Patrick McManus <[e-mail]>]

[co-chair hat on]

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

>
> > On 1 Nov 2016, at 22:50, Roy T. Fielding <[e-mail]> 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.
>
> 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).



>
>