Re: Invalid HTTP2 preface handling?

Amos,

that is a good way of doing it - more or less like an upgrade, but without
the complexity of having to inject the settings frame and HTTP/1 request
into the server.      While I hear what Mark says about caution, I really
don't see a great risk here and thus will look at supporting it also.

cheers



On 11 February 2015 at 11:34, Amos Jeffries <squid3@treenet.co.nz> wrote:

> 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
> >> ) 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...
> >
>
>
> 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.
>
> Amos
>
>
>


-- 
Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.