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

[Cory Benfield <[e-mail]>]

> On 2 Nov 2016, at 15:53, Werner Baumann <[e-mail]> wrote:
> 
> Am Wed, 2 Nov 2016 09:59:53 +0000
> schrieb Cory Benfield <[e-mail]>:
>> (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.

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.

>> 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. 

> 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.

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.

> 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.

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