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

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

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 9 Dec 2010 14:55:56 +1100
Cc: Brian McKelvey <theturtle32@gmail.com>, Joe Mason <jmason@rim.com>, Maciej Stachowiak <mjs@apple.com>, hybi HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <25E88686-BE24-4EFD-8330-25916C891664@mnot.net>
To: Bjoern Hoehrmann <derhoermi@gmx.net>

On 09/12/2010, at 2:45 PM, Bjoern Hoehrmann wrote:

> * Mark Nottingham wrote:
>> I still haven't seen anyone explain why CONNECT is better than, say, WEBSOCKET_PLEASE.
> 
> As I understand it, some people hope that the HTTP framing implied by
> "CONNECT" (essentially, anything the client sends after the server does
> send it's HTTP response is not interpreted as HTTP traffic) is very
> widely implemented, while a WEBSOCKET-specific method might follow a
> different code path in deployed implementations, whatever that might
> entail (it's common for servers to close the connection if they see a
> method they do not recognize, but who knows what the odd server does.)

CONNECT to a server (intermediary or origin) that isn't expecting it can and will be treated like any other method that isn't understood -- it's perfectly legitimate for a server to generate a 405 Method Not Allowed.  As such, using CONNECT isn't a guarantee that the message framing has changed on the request, until the server agrees to its semantics. Given that those semantics are specific to configured proxies, and an intermediary "agrees" by forwarding the message even when it doesn't understand its semantics, this is indeed an entirely hope-based assumption; that every intermediary (firewalls, virus scanners, caching proxies) is built to understand CONNECT, even when many of them can't be configured as an explicit proxy at all. 


>> Also, from a quick read of the archive, it appears that encoding the
>> stream (e.g., XOR, removing newlines, etc.) was shot down very quickly
>> because people couldn't do sendfile().
> 
> I think there is a rough consensus to do some XOR obfuscation if that
> is necessary or helpful, even though some would rather be able to do
> the easy sendfile() call instead, but the benefits are not very clear
> (if the attacker learns or can predict the XOR key, you've not gained
> much, in some scenarios anyway.)

I was thinking more about stripping newlines, etc., but yes, it's more expensive. Just not sure why that's an issue, which is why I asked...

> 
>> That makes me wonder: what are the use cases for using sendfile() with
>> WebSockets that can't be addressed by HTTP (more reliably, by everything
>> I've seen here)?
> 
> (I think the question would be more aptly put as an issue of "you can
> do this using simple commands to the hardware" versus "you have to
> pump everything through the main processor"; while static files would
> be a good example, you could also imagine, say, a camera that offers a
> "WebM" stream you'd like to direct directly at the network equipment.)

I see. I still wonder, given that HTTP streaming is evolving pretty fast, and realtime streaming requires UDP, not TCP. 

--
Mark Nottingham   http://www.mnot.net/
Received on Thursday, 9 December 2010 03:56:34 GMT

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