Re: workability (or otherwise) of HTTP upgrade

Julian Reschke wrote:
> >
> > My suggested fixes to 9.8, based on the notion that HTTP 1.0, 1.1
> > and 2.0, and PTTH 1.0, are not "incompatible" protocols:
> > ...
> Not convinced.
> If the protocol is compatible, you don't need "Upgrade" in the first
> place.

Two issues here.  One, is whether Upgrade should be a general-purpose
protocol tunneling mechanism vs. an HTTP-specific versioning mechanism.
Two, is how to change the wording.  There are probably specific terms
which describe exactly what I'm getting at, in languages other than
English (you Germans probably have an absurdly-long compound word that
captures exactly what I'm trying to say :-).

> So, HTTP/2.0 *will* need upgrade, if you start the conversation using 
> HTTP 1.*.

Of course.  I'm not arguing against Upgrade as a versioning mechanism
for HTTP and HTTP-ish protocols.  I can't imagine that HTTP 2.0 would
abandon the request/response or resource/representation paradigms,
which I'm suggesting be a requirement for protocols bound to port 80.

> > ...
> > This opens a whole can of worms about what constitutes a compatible
> > protocol, instead of the current wording:  "The capabilities and
> > nature of the application-layer communication after the protocol
> > change is entirely dependent upon the new protocol chosen," which
> > seems like the sort of free-for-all that leads to unintended
> > security consequences. ...
> Could you elaborate in these security consequences?

I mentioned context escaping in my last post to this thread, but I'm
really making more of a common-sense argument here.  How does one craft
potential exploits for protocols nobody's thought of yet?  Conversely,
how do we know it won't be possible?  It seems rational to me, that if
the security of the deployed architecture for port 80 is based on media
types, secure interoperability would be unlikely with protocols which
don't use media types.


Received on Tuesday, 30 November 2010 01:30:05 UTC