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

Re: HTTP/2.0 Magic

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 21 Feb 2013 20:15:15 +1300
Message-ID: <5125C983.70103@treenet.co.nz>
To: ietf-http-wg@w3.org
On 21/02/2013 7:12 p.m., 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.
>
> The distribution of latency on CLOSE (factoring out the round trip) is very heavy towards 0; see  the list at the end (some are negative because of jitter; connect time is used to estimate latency). Note the bumps at 1 and 3 seconds; I suspect these are timeouts in some load balancer or other middlebox, because their Server headers are pretty diverse.
>
> Just to see, what if we truncate the first one too?
>
> FOO\r\n\r\nBAR\r\n\r\n
>     1042 CLOSE
>       86 CONN_ERR
>    11766 TIMEOUT
>    
> Nope (stopped run when this became obvious). What about some binary?
>
> \xff * HTTP/2.0\r\n\r\n\xff\r\n\r\n
>    30271 CLOSE
>      342 CONN_ERR
>     4535 TIMEOUT
>     
> Huh. Not as good as text.


Couple of questions.
  How do the TIMEOUT failure sets compare to each other?
  are they all the same servers or do some respond badly to one form and 
CLOSE quickly on others?
  Is there any consistency in identifiable software doing TIMEOUT on any 
particular magic?


Amos
Received on Thursday, 21 February 2013 07:15:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 21 February 2013 07:15:48 GMT