- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 11 Feb 2015 11:03:09 +1100
- To: Greg Wilkins <gregw@intalio.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
> On 11 Feb 2015, at 10:48 am, Greg Wilkins <gregw@intalio.com> wrote: > > > Section 3.5 says: > > Clients and servers MUST treat an invalid connection preface as a > connection error ( > Section 5.4.1 > ) of type PROTOCOL_ERROR. A GOAWAY > 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... Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Wednesday, 11 February 2015 00:03:38 UTC