Re: comprehensive TLS is not the solution, it's a bug ... (was 2 questions)

Sorry for my not being aware of that as I am new to this list.

Any form of HTTP/1.1-based HTTP/2 protocol negotiation must allow a client to ignore hints of HTTP/2 availability and keep speaking HTTP/1.1.

How about this two-request protocol negotiation:

The first request is normal HTTP/1.1, and the server announces its HTTP/2 availability by including the string “HTTP/2” at the end of its Server header. This hint will be blissfully ignored by all older browsers that does not support HTTP/2, but it will be picked up by browsers supporting it.

The second request starts off with a HTTP/1.1 protocol upgrade to HTTP/2 and the server responds to the HTTP/1.1 protocol upgrade request with a HTTP/2 response, which will break non-HTTP/2 browsers (which is intentional here)

The browser can cache the HTTP/2 availability and all further communication, even a new session, can start with a HTTP/1.1 protocol upgrade and then full-blown HTTP/2 traffic.

> On Apr 1, 2015, at 02:55, Walter H. <Walter.H@mathemainzel.info> wrote:
> 
> On 31.03.2015 20:37, Maxthon Chan wrote:
>> Seem relevant, so I am just throwing it out here:
>> 
>> How about making TLS mandatory, and the URL scheme “http:” and “https:” only determines whether the certificate is checked or not?
> what should be the benefit of this behaviour?
> please think of the user/client side, not the server side when answering this;
>> Also since HTTP/1.1 have a protocol upgrade mechanism, how about using that as a stepstone of HTTP/2 (that is, all sessions is initiated as HTTP/1.1, and a HTTP/2-capable server tells the client it can start using HTTP/2 features in the resulting HTTP/1.1 header and further communications is HTTP/2)
> this is the only way; and the client must be able to refuse this and go further with HTTP/1.1 ...; and a client that is not capable of using HTTP/2.0 will hopefully ignore this ...
> 
> Greetings,
> Walter
>

Received on Tuesday, 31 March 2015 19:12:39 UTC