- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Thu, 09 Dec 2010 04:45:29 +0100
- To: Mark Nottingham <mnot@mnot.net>
- 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>
* 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.) >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.) >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.) -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Thursday, 9 December 2010 03:46:12 UTC