Re: h2 use of Upgrade

On Sep 4, 2014, at 11:09 AM, Martin Thomson wrote:

> On 3 September 2014 14:08, Roy T. Fielding <fielding@gbiv.com> wrote:
>> Yes, it contradicts RFC7230, which is a bad example to be setting.
> 
> The contradiction seems to be dependent on interpretation, given the
> actual usage of Upgrade, which is basically just websockets.

*sigh*

I've had dozens of questions about Upgrade over the years, not including
my own use of it for internal projects like HTTPng and waka.  It is mostly
used in situations where gradual deployment of services is a necessity,
which might include anything from printers to battlefield sensor arrays
integrated by field laptops and relayed to AWACS.  Most of those uses
are fairly ephemeral in nature -- gradually removed over time.

So, when you say that actual usage if Upgrade is just websockets, I just
have to laugh (and cry a little) inside.  Websockets is a toy.  Juvenile
at best, actively harmful at worst.  It only uses Upgrade in order to
tunnel a raw socket over port 80, which is something the IETF used to
regard as a really bad idea (back when the IETF was mostly run by sysops).

Let's pretend for a second that that the SPDY team understands the entire
scope of SPDY usage.  That covers about 5% of HTTP usage, by my estimate,
just based on what people have told me they are doing over the past 20
years because they wanted to ask me a question not covered in the RFCs.
I suspect that only a small portion of people doing unusual things with
HTTP bothered to ask me a question.  I have been editing for 20 years
and only seem to understand maybe 60-70% of how HTTP is used in practice,
based on how much new I learn each year.  There is always a gap.

Ignorance of the scope of HTTP is not a design virtue.  The only hope that
we have of getting things right with a protocol as widely used as HTTP
(and as fundamentally important as HTTP) is that somebody will tell us
when we are wrong.  Please don't drive them away by making bad assumptions
about their problem space.  We don't own the problem space.

>> Unless there is a strong reason to do so, and I have seen none here,
> 
> You obviously disagree, but I consider this to be a strong enough reason.
> 
> We did originally identify using the string "HTTP/2.0", but there were
> concerns raised about the length of that string and something of a
> lengthy discussion about the value of having distinct compartments in
> the string that had semantics (or implied semantics). The length
> concern is now less pressing since we know more about the bug in
> question, but we did choose not to revert the change.
> 
> The net outcome of the discussion was that no one was able to identify
> any value in having a regimented structure.  There was some discussion
> about the virtues of structure in general and the structure defined
> specifically in RFC 2817, but the conclusion there was that the value
> structure provides was outweighed by the simplicity of an opaque
> token.

Yes, well, that's why we have last calls.  The value of a regimented
structure with orthogonal protocols provided as separate tokens is
that orthogonal protocols are supposed to change independently,
versioned over time, and separate-but-consistent tokens allow recipients
to easily distinguish between layered options (like TLS + HTTP/2) and
distinct choices (like HTTP/1 | 2).  That rationale will undoubtedly
become clearer after a few more iterations on the ALPN token set.

Nevertheless, the only problem here is that h2 is setting a bad example.
Any token is valid.  The ALPN token could even be used as the version.
If you want to stick with a bad example, then so be it.  It is no worse
than the painfully stupid requirements regarding TLS that have been
imposed by those who know nothing about the problem space.


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <http://www.adobe.com/>

Received on Thursday, 4 September 2014 20:05:32 UTC