Re: HTTP/2.0 Magic

Hi Mark,

On Thu, Feb 21, 2013 at 05:12:56PM +1100, Mark Nottingham wrote:
> So, I decided to explore this a bit more. 
> 
> I have a list of about 760,000 IP addresses running Web servers, so I put together a quick script to see how they reacted to various magic strings.
> 
> For the source, see:
>   https://github.com/http2/http2-probe
> 
> Below are my notes from some preliminary experimentation today.
> 
> Just sending FOO\n\n to ~760,000 servers gives:
> 
> FOO\n\n
>  641481 CLOSE
>   85855 CONN_ERR
>   35148 TIMEOUT
> 
> "CLOSE" means that the server closed the connection; "CONN_ERR" was various connection errors, 
> and "TIMEOUT" means it hangs (5 seconds, in this case).
> 
> Let's try adding \r before the \n (all of the following runs are on the TIMEOUTs above).
> 
> FOO\r\n\r\n
>    1602 CLOSE
>     303 CONN_ERR
>   33243 TIMEOUT
> 
> A bit of help. What if we give it HTTP syntax?
> 
> FOO * HTTP/2.0\r\n\r\n
>   30082 CLOSE
>     396 CONN_ERR
>    4670 TIMEOUT
> 
> Much better. What if we add Connection: close?
> 
> FOO * HTTP/2.0\r\nConnection: close\r\n\r\n
>   30310 CLOSE
>     337 CONN_ERR
>    4501 TIMEOUT
> 
> Not significantly better. What if we do Content-Length: 0 instead?
> 
> FOO * HTTP/2.0\r\nContent-Length: 0\r\n\r\n
>   30072 CLOSE
>     369 CONN_ERR
>    4707 TIMEOUT
> 
> Not helping. What if we add a second "request"?
>   
> FOO * HTTP/2.0\r\n\r\nBAR * HTTP/2.0\r\n\r\n
>   31212 CLOSE
>     306 CONN_ERR
>    3630 TIMEOUT
> 
> Significantly better. Can we save the \r?
> 
> FOO * HTTP/2.0\n\nBAR * HTTP/2.0\n\n
>   27101 CLOSE
>     312 CONN_ERR
>    7735 TIMEOUT
> 
> Ouch. Does it need the full second request, or just some bits?
> 
> FOO * HTTP/2.0\r\n\r\nBAR\r\n\r\n
>   31132 CLOSE
>     427 CONN_ERR
>    3589 TIMEOUT
>    
> Not bad; our best candidate. About 175 out of the 3589 remaining TIMEOUTs on
> the do send some text (most often, a HTTP status code), but that's not the
> majority; most of them well and truly hang.

(...)

That's a great test, thanks for reporting this !
I think that some experiments may be pursued using :
  - valid, known methods and versions (eg: POST * HTTP/1.1)
  - Connection header

I suspect that POST will be blocked on a large number of minimal web
servers (the least compliant ones), add to that "*" which will most
often not be accepted, and HTTP/1.1 without a Host header field might
help getting a quick fail. At this point, I don't know if a Connection
header could help or not (typically Upgrade).

Cheers,
Willy

Received on Thursday, 21 February 2013 07:06:51 UTC