Re: workability (or otherwise) of HTTP upgrade

On 26.11.2010 08:03, Eric J. Bowman wrote:
> ...
> Shouldn't a line be drawn between what's appropriate for port 80, and
> what constitutes an entirely different protocol?  Or is the intent of
> Upgrade to deprecate registering new URI schemes in favor of a registry
> of HTTP tokens?
> ...

That would be material for "Upgrade Token Registry" section...

> ...
> It's perhaps fundamentally flawed for HTTP to be the handshake mechanism
> for protocols that are not even remotely similar to HTTP.  In this case,
> we have a half-duplex, request/response, resource/representation
> protocol establishing a full-duplex, asynchronous, opaque-bits-on-the-
> wire connection that's fundamentally incompatible with the deployed
> architecture of port 80 (caches, security gateways); and which nobody
> seems happy with.
> 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.

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

"HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of 
the protocol. The protocol versioning policy is intended to allow the 
sender to indicate the format of a message and its capacity for 
understanding further HTTP communication, rather than the features 
obtained via that communication. No change is made to the version number 
for the addition of message components which do not affect communication 
behavior or which only add to extensible field values. The <minor> 
number is incremented when the changes made to the protocol add features 
which do not change the general message parsing algorithm, but which 
might add to the message semantics and imply additional capabilities of 
the sender. The <major> number is incremented when the format of a 
message within the protocol is changed."

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

 > ...

Best regards, Julian

Received on Friday, 26 November 2010 13:34:06 UTC