W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: [hybi] workability (or otherwise) of HTTP upgrade

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Tue, 07 Dec 2010 22:38:46 +0000
Message-ID: <AANLkTik4zgrqqbzWSmuRjS78Ur5ZOeejnP=Zu2usXh6D@mail.gmail.com>
To: Dave Cridland <dave@cridland.net>
Cc: Maciej Stachowiak <mjs@apple.com>, Server-Initiated HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Mark Nottingham <mnot@mnot.net>
On Tue, Dec 7, 2010 at 3:42 AM, Dave Cridland <dave@cridland.net> wrote:
> On Mon Dec  6 23:27:02 2010, Maciej Stachowiak wrote:
>>
>> I'd like to see more detail on the data than is found in the paper, but it
>> seems to show a real-world hazard with use of Upgrade, since many
>> intermediaries do not understand it and at least a few are confused into
>> treating subsequent traffic as additional HTTP requests and responses.
>
> That's a subtle misread of the paper.
>
> The paper shows that many intermediaries treat any traffic as HTTP requests
> and responses until they find a CONNECT, after which they treat the traffic
> as opaque except in a tiny minority of cases (what, 4 out of 54,000?).

I do not think the paper corroborates that argument at all.

Quoting the paper: "In our experiments, we observed two proxies which
appear not to understand CONNECT but simply to treat the request as an
ordinary request and then separately route subsequent requests, with
all routing based on IP address."

Sounds simple and clear, but let's dig a little deeper. The
experiments sent bytes in the following form (as far as we know, from
conversations on this mailing list)

  CONNECT websocket.invalid:443 HTTP/1.1
  Host: websocket.invalid:443
  Sec-WebSocket-Key: <connection-key>
  Sec-WebSocket-Metadata: <metadata>

  GET /script.php/<random> HTTP/1.1
  Host: target.com

that is, two HTTP requests, well formed. An HTTP interceptor that
understands CONNECT will treat the load(all bytes after the connect
request) as opaque and forward them to the server verbatim.

On the other hand, a "CONNECT-agnostic" HTTP interceptor, one that
does not "understand CONNECT but simply to treat the request as an
ordinary request and then separately route subsequent requests, with
all routing based on IP address", will do ... pretty much the same
thing! It could have parsed the load into a HTTP request, then sent
the request to the server as is, effectively forwarding the load to
the server verbatim. Neither the client nor the server could detect
the fact that this interceptor parsed the load as HTTP requests.

Some CONNECT-agnostic interceptors may have touched the 2nd request in
some way, allowing the server to detect them. The two proxies
described in the paper may have done something like that. It would
nice if the authors tell us how exactly they are detected.

Other than that though, how many other interceptors are
CONNECT-agnostic? I don't see how you can even make a wild guess based
on the experiments conducted.

See also my previous inquires about the experiments (yet to be answered)
http://www.ietf.org/mail-archive/web/hybi/current/msg04971.html
http://www.ietf.org/mail-archive/web/hybi/current/msg04972.html

- Zhong Yu
Received on Wednesday, 8 December 2010 14:57:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:33 GMT