W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: Invalid HTTP2 preface handling?

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 11 Feb 2015 13:34:44 +1300
Message-ID: <54DAA3A4.8060608@treenet.co.nz>
To: ietf-http-wg@w3.org
On 11/02/2015 1:03 p.m., Mark Nottingham wrote:
>> On 11 Feb 2015, at 10:48 am, Greg Wilkins wrote:
>> Section 3.5 says:
>>    Clients and servers MUST treat an invalid connection preface as a
>>    connection error (
>> Section 5.4.1
>>    frame (
>> Section 6.8
>> ) MAY be omitted in this case, since an invalid
>>    preface indicates that the peer is not using HTTP/2.
>> I'm wondering what would be the problem if on an invalid preface, the server check if it is actually a valid HTTP/1 request and if so, then to proceed on that basis?     This would allow a server to converse a HTTP/1 client that is pointed at a HTTP/2 port - it could be application specific if that conversation was an error message or just a normal HTTP/1 conversation.
>> Is there some attack we would be enabling if we allowed such behaviour in our server?  Anything else undesirable about doing this?
> The client and server have a different idea of what protocol they're talking (however they got there); using a heuristic ("that looks like HTTP/1") is asking for trouble; we've had a history of attacks tricking protocol stacks into thinking they're in a different state...

FWIW I am doing it the other way around in Squid. With a one-way upgrade
from HTTP/1 to HTTP/2 raising both the capabilities and processing
strictness. If at any time a request-line matches the full HTTP/2 magic
prefix it completes outstanding transactions then switches the
connection irrevocably to talking HTTP/2. Treating the connection as if
it had just been opened with native HTTP/2.

Due to HTTP/2's stricter compliance requirements there seem to be no
security issues over what would happen anyway for Upgrade: requests -
and the simpler operation also means less potential bugs.

Received on Wednesday, 11 February 2015 00:35:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:43 UTC