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

Am Wed, 2 Nov 2016 09:59:53 +0000
schrieb Cory Benfield <cory@lukasa.co.uk>:
> (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.

Received on Wednesday, 2 November 2016 15:54:42 UTC