Subject: Re: Proposal: 205 Bodies [#88]

From: Julian Reschke <[email-masked]>
Date: Mon, 25 Oct 2010 17:23:01 +0200

On 11.06.2009 11:58, Roy T. Fielding wrote:
> On Jun 11, 2009, at 11:39 AM, Julian Reschke wrote:
>
>> Mark Nottingham wrote:
>>> We have a similar situation around request bodies --
>>>> A message-body MUST NOT be included in a request if the
>>>> specification of the request method (Section 2 of [Part2])
>>>> explicitly disallows an entity-body in requests.
>>> What I'd like to do in both cases is make it more apparent that the
>>> list of exceptions is closed, by not predicating it on an external
>>> MUST NOT.
>>
>> That's a good point.
>>
>>> In the case for requests, I think the entire sentence disappears,
>>> because we have not specified any method that disallow request bodies
>>> (unless one of the many WebDAV methods places this requirement on
>>> requests, and even then...).
>>
>> Nope, WebDAV doesn't do that.
>>
>> From RFC2616 I see two potential candidates: (1) TRACE (which uses the
>> same terminology as the 205 status that started this thread: "MUST NOT
>> include an entity"), and (2) CONNECT (?).
>
> There are no candidates. Any change to the message parsing algorithm
> would require a major bump in HTTP version.
 > ...

In the meantime, the parsing section in Part 1 has been revised.

I believe we still need to rephrase the description of 205, currently 
saying:

"The response MUST NOT include a message-body."

Proposal:

"The message-body included with the response MUST be empty."

(<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/88/i88.diff>)

Best regards, Julian

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 26 Oct 2010 10:45:05 +1300

>> would require a major bump in HTTP version.

in relation to CONNECT, I think we can justify giving it special 
treatment for several reasons:

1. It's not part of the original spec, but an extension designed to 
enable arbitrary connectivity through a compliant proxy
2. It already has very specific requirements which make it very 
un-HTTP-like (e.g. the proxy connects and gets out of the way), no HTTP 
is (necessarily) used upstream.

In fact in our code-base the special handling for CONNECT is much more 
involved than for say HEAD.  I find it hard to conceive of a proxy that 
wouldn't treat CONNECT as a very special case already.

In the one case where I've seen a body on a CONNECT method (blu-ray 
player), if that body were passed through to the end server, it broke 
things.

If you allow bodies on a method, then Content-Length is required.  I 
don't see any Content-Length headers on CONNECT messages, so current 
browsers would become incompatible.

Can we allow Transfer-Encoding: chunked on CONNECT?  IMO we can't.

Adrien

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 25 Oct 2010 23:54:01 +0200 (CEST)

> Can we allow Transfer-Encoding: chunked on CONNECT?  IMO we can't.

Why not? I've seen proxies respond with chunked CONNECT responses (for 407 
bodies).

-- 

  / daniel.haxx.se

---

From: Adrien de Croy <[email-masked]>
Date: Tue, 26 Oct 2010 11:06:18 +1300

I guess the confusing issue is what is the purpose or meaning of a body 
on a CONNECT request message?  What should a proxy do with it?  The only 
case I've seen, the only thing that worked was discarding the body.  So 
WinGate now discards all bodies on CONNECT requests.

If they are supposed to be forwarded after the connection is made, then 
the message would need to be completed before this is done, so if 
chunked, a 0 chunk would have to have been received.

I imagine it's fairly common to get chunked bodies on 407 response 
messages regardless of the request method.

So I guess I take it back about whether chunking should be allowed, but 
I still suggest bodies should be disallowed.

The other non-standard thing about CONNECT is the reusability of the 
connection, and connection state management.  For instance, is it 
required for all successful responses to CONNECT to specify Connection: 
close? Since that's the only way to specify that the connection cannot 
be used for anything else afterwards, which we all know is actually the 
case, since HTTP framing is lost as soon as the response message is 
completed.

On 26/10/2010 10:54 a.m., Daniel Stenberg wrote:
> Why not? I've seen proxies respond with chunked CONNECT responses (for 
> 407 bodies).
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Oct 2010 10:11:29 +1100

If anything, I'd be inclined to make this even more explicit; e.g.,

"A 205 response body MUST be empty. Note that receivers will still parse the response according to the algorithm defined in [ref to p1]."

On 26/10/2010, at 2:23 AM, Julian Reschke wrote:

> I believe we still need to rephrase the description of 205, currently saying:
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Oct 2010 10:33:55 +0200

> Can we allow Transfer-Encoding: chunked on CONNECT? IMO we can't.

I think we are in agreement that CONNECT, once we add it to the spec, 
needs more work (see issues 250 and 251).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 Oct 2010 14:08:40 +0200

> "A 205 response body MUST be empty. Note that receivers will still parse the response according to the algorithm defined in [ref to p1]."

"The message-body included with the response MUST be empty. Note that 
receivers still need to parse the response according to the algorithm 
defined in Section 3.3 of [Part1]."

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1058>.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 26 Oct 2010 18:18:49 +0200

> browsers would become incompatible.

I have seen one implementation systematically add "Content-Length: 0"
to CONNECT responses. I believe those were NetApp proxies. Anyway, it
just enforces the fact that there is no body.

> Can we allow Transfer-Encoding: chunked on CONNECT?  IMO we can't.

Indeed it would be problematic to have "0\r\n" prepended to data !

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 26 Oct 2010 18:24:33 +0200

> I still suggest bodies should be disallowed.

The only problem is with the 200 response. We could insists that this specific
code does not allow any body.

> case, since HTTP framing is lost as soon as the response message is 

It's not the only way, because the lack of a content-length and
transfer-coding also implies the close.

In haproxy, I solved the issue differently. I don't consider the connection
is reusable or anything else, the connection switches to a "tunnel" mode
once it has been confirmed with the 200. The "tunnel" mode is a bidir TCP
stream. Considering that we rely on close would imply that we consider
messaging, but messaging does not necessarily mean that the data can flow
in both directions. If we didn't have existing implementations, I would
even not be shocked to consider that we forward bodies in both directions
up to their content lengths, and that after those bodies (end of messages
after all), the connection becomes bidirectional. Doing that now would be
scary though.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Oct 2010 12:58:05 +1100

I think we can specify:

1) CONNECT requests MUST have a zero-length body (same language referring to p1 as we used for 205)
2) CONNECT responses that are successful (2xx) MUST have a zero-length body, because the tunnel begins after the header block.

Thoughts?

On 26/10/2010, at 7:33 PM, Julian Reschke wrote:

> I think we are in agreement that CONNECT, once we add it to the spec, needs more work (see issues 250 and 251).
> 
> Best regards, Julian
>

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 27 Oct 2010 05:52:32 +0200

> 2) CONNECT responses that are successful (2xx) MUST have a zero-length body, because the tunnel begins after the header block.

I think this is fine. Concerning the last point, I think we could still
improve it a bit. By default, if there is no C-L, a user agent (or a
gateway) may consider that the body runs till the close (as it does
with other methods or statuses). As it is here, it makes one think that
it is mandatory to send a content-length: 0. Maybe we should word it
slightly differently, by first indicating that the tunnel begins after
the header block, then that the receiver of the response must ignore any
body in such a case. Maybe something around this :

 2) Successful CONNECT responses (2xx) indicate that the tunnel begins
    immediately after the header block, regardless of any Content-Length or
    Transfer-Encoding headers, which MUST be ignored by the recipient. These
    responses MUST have a zero-length body and MUST NOT be transfer-encoded.

Any thoughts ?
Willy

---

From: "William A. Rowe Jr." <[email-masked]>
Date: Tue, 26 Oct 2010 23:29:33 -0500

>     responses MUST have a zero-length body and MUST NOT be transfer-encoded.

The closer we can get to the language in 10.1.2 101 Switching Protocols the more
likely this message will be clearly understood.

---

From: Adam Barth <[email-masked]>
Date: Wed, 27 Oct 2010 00:31:26 -0700

There are use cases for including a non-zero length body in an CONNECT
request.  For example, draft-abarth-websocket-handshake includes some
additional data with the CONNECT request.  Of course, we could put
that data in a header, but it seems to make sense as an entity-body.

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Oct 2010 11:52:44 +1100

If you're referring to section 1.1 step 7 -- that's not really an appropriate use of CONNECT, according to its definition. POST would be more so (although the criticism that it's not really HTTP that's being spoken still holds).

Cheers,

---

From: Adam Barth <[email-masked]>
Date: Wed, 27 Oct 2010 20:06:50 -0700

Why isn't CONNECT appropriate?  We're trying to negotiate a
bidirectional channel after receiving the server's response.  Seems a
lot like CONNECT + Proxy-Authentication giving you a bidirectional
channel for TLS.

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Oct 2010 14:14:53 +1100

Because CONNECT is for establishing a connection to a proxy, not a gateway (which is what you're doing).

Also, I suspect putting a body on a CONNECT request is going to lead to interop problems (which is what led to #251).

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 28 Oct 2010 07:48:25 +0200

> Because CONNECT is for establishing a connection to a proxy, not a gateway (which is what you're doing).

That's true but the semantics of the CONNECT method is the closest to what we
need in WebSocket. After all, we're negociating a bidirectionnal tunnel between
the browser and the application through the HTTP infrastructure.

> Also, I suspect putting a body on a CONNECT request is going to lead to interop problems (which is what led to #251).

And possibly to request smuggling attacks, which was one reason for
choosing CONNECT. We should stay on the compatibilty side IMHO, and
I too am worried about the possible implications of sending a body
with a CONNECT.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Oct 2010 16:53:47 +1100

> the browser and the application through the HTTP infrastructure.

This is neither horseshoes nor hand grenades. CONNECT is unique (and badly designed, as a method) because it doesn't go through, it terminates at the proxy. Sending a CONNECT to an origin server makes no sense, and is likely to be blocked by all sorts of infrastructure. 

You'd be better off using Upgrade, which is very much designed for this use case.

---

From: Adam Barth <[email-masked]>
Date: Wed, 27 Oct 2010 22:59:51 -0700

> You'd be better off using Upgrade, which is very much designed for this use case.

Unfortunately using Upgrade for WebSockets causes security
vulnerabilities because many intermediaries don't understand its
semantics and ignore it.  On the other hand, CONNECT is widely used
and has the behavior we want.

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Oct 2010 17:04:16 +1100

Intermediaries that aren't expecting CONNECT are just as likely to ignore it (i.e., many, but not all, will error out, whereas the rest will pass it through). E.g., try CONNECTing to Squid running as a transparent proxy, or against a L7 load balancer, or...

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 28 Oct 2010 08:05:15 +0200

> This is neither horseshoes nor hand grenades. CONNECT is unique (and badly designed, as a method) because it doesn't go through, it terminates at the proxy. Sending a CONNECT to an origin server ma…

Not exactly in fact. Components that support being placed in front of proxies
(load balancers, IPS, ...) will automatically support it provided we respect
the way it's used with proxies, while they will not all necessarily support
the Upgrade. Those who wont support CONNECT are likely the sames which won't
support Upgrade.

> You'd be better off using Upgrade, which is very much designed for this use case.

I agree with the design part. But Adam found one situation where he thinks
that Upgrade through a non-compatible infrastructure could be used by an
attacker's site to make a browser inject requests to another site, if my
memory serves me right. While I still think this is marginal, I'd rather
use the safest approach that is fully compatible with HTTP and with the
needs of WS. (Which also means that if we can't get CONNECT to correctly
work, then Upgrade would probably fit the purpose).

Regards,
Willy

---

From: Adam Barth <[email-masked]>
Date: Wed, 27 Oct 2010 23:07:22 -0700

That's true, but we don't know of any non-TLS WebSocket handshake that
connects more than about half the time.  If you want to reliably
connect to the server, you need to use TLS.

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Oct 2010 17:13:40 +1100

Use something other than port 80, since you're not speaking HTTP?

But I digress; that's a discussion to be had when / if WebSockets goes to IETF Last Call. Back to the topic at hand: 

What property are you looking for out of using the CONNECT method to the server that rules out other methods?

What specific security vulnerabilities are raised by using Upgrade (a useful discussion to be had in any case)?

Regards,

---

From: Adam Barth <[email-masked]>
Date: Wed, 27 Oct 2010 23:33:59 -0700

> But I digress; that's a discussion to be had when / if WebSockets goes to IETF Last Call. Back to the topic at hand:

Sure.  To answer you question: it's one of the requirements:

   REQ. 7:  The WebSocket protocol MUST allow HTTP and WebSocket
      connections to be served from the same port.

http://tools.ietf.org/html/draft-ietf-hybi-websocket-requirements

> What specific security vulnerabilities are raised by using Upgrade (a useful discussion to be had in any case)?

There are a lot more details in
<https://docs.google.com/document/edit?id=1hRLcVc8FHsXOQvaulG2KmvGKepgFffcevyJn-dAEsrI&hl=en&authkey=COOWhaAD>,
but the high-level idea is that there a bunch of network
intermediaries that listen to traffic and think they understand HTTP.
Unfortunately, these boxes are much better at understanding
HTTP-as-she-be-spoke rather than HTTP-as-specified (to borrow a
neologism from the HTML WG).

>From CONNECT, specifically, we'd like to get WebSocket-oblivious
intermediaries to ignore the rest of the bytes on the socket.  CONNECT
lets them know that the rest of the bytes coming from the client
aren't going to be HTTP, so they shouldn't try to understand the
semantics of those bytes.

If everyone perfectly implemented HTTP-as-specified, we could use
Upgrade for that purpose because that's what Upgrade is supposed to
mean also.  Unfortunately, Upgrade is extremely rare in
HTTP-as-she-be-spoke, which means many of these intermediaries think
that the subsequent bytes sent by the client have HTTP semantics.  Of
course, in WebSockets, the attacker is given great latitude to select
bytes-on-the-wire after the handshake completes, which means the
attacker's script running in a browser can craft bytes that look a lot
like HTTP but avoid the security invariants the browser usually
imposes on script code running on behalf of a web site.

Most notably, the attacker can spoof the Host header.  If you consider
an enterprise deployment with a firewall and a transparent (Roy will
correct me that the proxy isn't technically transparent, but that's
folks call it) proxy (which is a common deployment pattern), the
attacker can sometimes get the transparent proxy to retrieve HTTP
resource otherwise protected by the firewall.  For example, stealing
product plans from an internal wiki.

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Oct 2010 18:06:26 +1100

> http://tools.ietf.org/html/draft-ietf-hybi-websocket-requirements

Presence in a requirements document doesn't guarantee that any given feature will get through. Considering the hoops you're having to jump through to meet this requirement (does the reqs document have consensus, by the way?), it's a wonder it's still considered relevant.

In other words, who actually *wants* this?

> <https://docs.google.com/document/edit?id=1hRLcVc8FHsXOQvaulG2KmvGKepgFffcevyJn-dAEsrI&hl=en&authkey=COOWhaAD>,

Thanks.

> semantics of those bytes.

Explicitly configured forward proxies -- as opposed to "reverse" proxies, interception (a.k.a. "transparent") proxies, L7 load balancers, firewalls and the like -- will indeed do this. Whether any of the rest will is anyone's guess, and depends upon how they're coded, whether they're ever used as a forward proxy, and how generous / clued-up the administrator is. 

> that the subsequent bytes sent by the client have HTTP semantics.

How does that follow?

Upgrade is an optional mechanism. The client requests upgrade, and the server decides whether or not it's upgrading the protocol; if it does, it uses a 101 Switching Protocols response.

That, however, is predicated upon the presence of the Upgrade header in the request. Upgrade is hop-by-hop, which means that it'll be removed by well-behaved intermediaries, unless they understand the protocol being upgraded to. 

For the remainder (i.e., the not-well-behaved intermediaries), in my testing setting the appropriate Connection: header catches pretty much all of them.

E.g.,

POST /foo HTTP/1.1
Host: example.com
Upgrade: WebSockets/5.0
Connection: Upgrade

will catch almost every deployment (certainly more than could be characterised as "extremely rare").  The ones that aren't can be worked around, because they're only deployed server-side (e.g., Pound, nginx).

>  Of

You're missing the point here -- a box that isn't expecting and explicitly handling CONNECT will also think that HTTP semantics apply beyond the end of the message. 

> folks call it)

Correct term is 'interception proxy'.

> proxy (which is a common deployment pattern), the

If you're looking to prevent that type of attack, CONNECT isn't going to be sufficient. See discussion re: using another port.

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 28 Oct 2010 09:23:07 +0200

> In other words, who actually *wants* this?

I'd pose the question the other way around : how could we replace existing
long-polling mechanisms that already work over HTTP and benefit from all
features that have been built around HTTP, on a different port. Right now,
virtual hosting, ability to be proxied any number of times, including through
URL filters (think about schools), session state management and server
stickiness are essential to web applications nowadays. If we're going to
use a distinct port, we're losing most of these existing features, which
will considerably lower adoption.

> Explicitly configured forward proxies -- as opposed to "reverse" proxies, interception (a.k.a. "transparent") proxies, L7 load balancers, firewalls and the like -- will indeed do this. Whether any…

Pure reverse proxies will probably not work, just as they currently don't
work with 101 either. Firewalls and load balancers do support explicit
proxies (those were the first users of load balancers) and as such are
well aware of the methods used in such environments. There's still the
common issue of proxy-connection vs connection but there's already a bug
open on the subject.

> That, however, is predicated upon the presence of the Upgrade header in the request. Upgrade is hop-by-hop, which means that it'll be removed by well-behaved intermediaries, unless they understand…

There are more stupid implementations. One of them was done by me. First
incarnations of haproxy did not consider the status codes and used to pass
them to the other side. However, I'd say that it did not support keep-alive.
Recently I fixed it for 1xx support and was contacted about the fact it broke
websocket (I considered 101 as equivalent of 100). This last specific case
is what saves us after all.

After saying that, I'm realizing that maybe we're seeing the issue the wrong
way :
  - if an implementation does not correctly handle 1xx, it cannot support
    keep-alive, so I don't see how we could have a security issue

  - if an implementation supports 101 as 100, it will break on the end of
    the handshake which won't look like an HTTP status anymore.

  - if it supports 101, then fine.

> will catch almost every deployment (certainly more than could be characterised as "extremely rare").  The ones that aren't can be worked around, because they're only deployed server-side (e.g., Pou…

That was my observation too.

> You're missing the point here -- a box that isn't expecting and explicitly handling CONNECT will also think that HTTP semantics apply beyond the end of the message. 

But do we have any chance to spot any such implementation ? That was one of
my concern in the early days when I too proposed CONNECT, but if the
implementation is server-side only, it generally does not support CONNECT,
which is fine. And if it supports relaying to proxies it will support it
with correct semantics.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Oct 2010 20:00:10 +1100

On 28/10/2010, at 6:23 PM, Willy Tarreau wrote:
> virtual hosting

WebSockets on a separate port can easily identify the intended host, just as HTTP does...

> , ability to be proxied any number of times

... but as proposed, it's not, because it's so extremely brittle...

> , including through URL filters (think about schools)

... which will either block WS as a policy decision, or just block by host/port combination anyway...

> , session state management

... which can already span multiple hosts and ports...

> and server stickiness

... which would also be available on a separate port...

> are essential to web applications nowadays. If we're going to

As you can probably tell, I don't buy it.

> proxies (those were the first users of load balancers)

They support *being* a proxy, or being a proxy behind a firewall. The question here is whether they support connections *through* them using CONNECT to another proxy. E.g., Checkpoint's URL filtering and web protection stuff, and lots of other products besides.

> and as such are

[...]

> which is fine. And if it supports relaying to proxies it will support it

No. Nothing requires an intermediary to support CONNECT, and if they don't, nothing prevents them from treating it like any other HTTP message; i.e., delimited according to HTTP, and followed by more HTTP messages. 

Cheers,

---

From: Adam Barth <[email-masked]>
Date: Thu, 28 Oct 2010 10:36:41 -0700

This sounds like a valuable discussion to have in the HyBi working
group.  I'm not sure we've got all the right folks on this mailing
list to respond to your feedback.

Adam

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 28 Oct 2010 22:23:37 +0200

> ... which would also be available on a separate port...

Are you suggesting to be HTTP compliant but to just use a different port ?
If so, then I agree that we can easily reuse existing infrastructure without
implying risks on existing shared hosting environments. But it's not clear
to me that it is what you're talking about. My understanding is that you
want to get rid of the HTTP compatibility which at the same time would
require to reinvent all the components to offer the features above.

I think that it is a solution which has never been suggested on the hybi WG
to use HTTP over a different port. Either it was HTTP on same port with
horrible tricks, or something very different and incompatible on a dedicated
port. The more I think about it, the more I like the principle of HTTP over
another port !

> As you can probably tell, I don't buy it.

I've noticed, but your wording does not make it clear to me what you're
proposing.

> They support *being* a proxy, or being a proxy behind a firewall. The question here is whether they support connections *through* them using CONNECT to another proxy. E.g., Checkpoint's URL filteri…

I was not talking about them being a proxy but clearly being installed in front
of a proxy. I know for sure that haproxy works. Alteon used to work last time I
tested (years ago). I'm pretty sure that Cisco ACE works. I don't know for them
all, but what I mean is that it's common to install a load balancer before a
proxy, which is transparent to both sides.

BTW, I'm suspecting we're getting off-topic for this WG and that this discussion
should move to hybi.

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 29 Oct 2010 10:09:44 +1100

It (i.e., not using port 80) has already been raised many times, doubtless it'll be raised again.

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 29 Oct 2010 10:13:06 +1100

> port. The more I think about it, the more I like the principle of HTTP over

If the request-line doesn't have HTTP/ in it, I don't care what it does on another port... however, if I were actually designing WebSockets to be a successful protocol, I don't know that I'd want to be constrained to HTTP syntax, given that it's not getting much benefit from doing so. The concepts that you're interested in can be reused without dragging along all of the baggage.

> BTW, I'm suspecting we're getting off-topic for this WG and that this discussion

Hey, that's my job :)

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 29 Oct 2010 07:40:14 +0200

> If the request-line doesn't have HTTP/ in it, I don't care what it does on another port... however, if I were actually designing WebSockets to be a successful protocol, I don't know that I'd want t…

But still they need to be reinvented for the new protocol, and components to
be redevelopped. Right now, HTTP-compatible infrastructure offers all of that
for free. Host, URI and cookies are used a lot along the chain to direct the
client's connection to the proper component of the proper server of the proper
farm, and all of that already exists.

Infrastructure components are sensible and rarely upgraded. Doing so requires
a very long qualification process, and if this is needed to offer compatibility
with WebSocket, many developers will have no choice but stay with Comet and the
like for their new devs.

However, saying that they work the same as before on another port indeed makes
a lot of sense. Nothing would even prevent them from sharing the same port if
they want and they know their infrastructure is compatible.

> > BTW, I'm suspecting we're getting off-topic for this WG and that this discussion

Sorry :-)

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 29 Oct 2010 16:41:14 +1100

> farm, and all of that already exists.

It's not free, as evidenced by the hoops that are being jumped through to try to make sure that it isn't treated like HTTP.

Anyway.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 29 Oct 2010 08:07:17 +0200

> It's not free, as evidenced by the hoops that are being jumped through to try to make sure that it isn't treated like HTTP.

No, we're trying to make sure it *is* treated like HTTP even on non
completely HTTP compliant stacks which could possibly treat the tunnelled
data as HTTP too while they must not. Otherwise, the 101+upgrade perfectly
fits the purpose.

Willy

---

From: Adrian Chadd <[email-masked]>
Date: Fri, 29 Oct 2010 14:28:54 +0800

> data as HTTP too while they must not. Otherwise, the 101+upgrade perfectly

I know I've asked this before, but what about devices that wish to pull apart
the CONNECT traffic (MITM security appliances) and, deciding the traffic
isn't actually HTTP, quite rightly denies it?

What about statistical fingerprinting of traffic? (ie, fingerprinting
whether a CONNECT session is likely to be HTTP or not based on exchanged
traffic patterns.)

Adrian

---

From: Adam Barth <[email-masked]>
Date: Thu, 28 Oct 2010 23:37:59 -0700

> whether a CONNECT session is likely to be HTTP or not based on exchanged

All that stuff appears as a failure to establish a WebSocket
connection.  All the WebSocket handshakes we know have an empirical
failure rate of about 50%.  If you want to connect more reliably, you
need to use the TLS version.

Adam

---

From: Juan M. Sierra Lebrón <[email-masked]>
Date: Fri, 29 Oct 2010 09:54:27 +0200

We send this mail from a law firm.
We are not interested in receiving emails advertising.
Under Law 34/2002 of 11 July, Services of information society and electronic commerce, you are notified about the responsibility that you may incur if you keep sending emails.
We want that our data are deleted from its database
Sincerely.

EVIAL ASESORES
Juan M. Sierra Lebrón
[email-masked] 
C/ Pau Claris, 190 - 2º 1ª  -  08037 Barcelona
Telf. 935 157 234 -  Fax 934 873 677

Cláusula confidencial
El contenido de este mensaje y cualquier documento adjunto al mismo son confidenciales. Tienen el sólo propósito de su uso por el individuo o entidad designado como receptor. Si recibe este mensaje por error, se le informa, que su lectura, divulgación, copia o distribución está estrictamente prohibida y le rogamos nos lo notifique por e-mail a ([email-masked]).
 Antes de imprimir este e-mail, piense bien si es necesario hacerlo.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Mark Nottingham
Enviado el: viernes, 29 de octubre de 2010 1:13
Para: Willy Tarreau
CC: Adam Barth; Julian Reschke; Adrien de Croy; HTTP Working Group
Asunto: Re: #250 / #251 (connect bodies)

Hey, that's my job :)

Cheers,

---

From: Juan M. Sierra Lebrón <[email-masked]>
Date: Fri, 29 Oct 2010 09:56:49 +0200

EVIAL ASESORES
Juan M. Sierra Lebrón
[email-masked] 

Cláusula confidencial

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Adrian Chadd
Enviado el: viernes, 29 de octubre de 2010 8:29
Para: Willy Tarreau
CC: Mark Nottingham; Adam Barth; Julian Reschke; Adrien de Croy; HTTP Working Group
Asunto: Re: #250 / #251 (connect bodies)

Adrian