Subject: Re: [hybi] Web sockets and existing HTTP stacks

From: Ian Hickson <[email-masked]>
Date: Sun, 31 Jan 2010 09:22:57 +0000 (UTC)

(-cc whatwg)

On Sat, 19 Dec 2009, Greg Wilkins wrote:
>
> To support websocket in Jetty, we had to use our existing HTTP stack 
> because we don't know that the request is a websocket upgrade until we 
> have already accepted it and parsed it using our existing HTTP stack.

Well, yeah. That's going to be the case with any protocol that shares its 
port with HTTP. Web Socket tries to make this easier by making it at least 
_possible_ to parse the header with an HTTP stack, if not necessarily 
easy.

On Fri, 18 Dec 2009, Justin Erenkrantz wrote:
> 
> Ditto - this is a critical problem with the current websocket RFC.  I 
> would place more credence into the argument that websocket RFC has 
> nothing at all to do with HTTP if it didn't rely upon the HTTP/1.1 
> Upgrade semantics. Either it's related, or it's not.

It's related in the sense that it shares the port and is designed such 
that its handshake can be interpreted as an HTTP Upgrade request. It's 
unrelated in that it is an independent protocol and doesn't need to be 
bootstrapped off HTTP in any way.

> Let's please not make the mistake of trying to tunnel protocols thru 
> HTTP firewalls just because you think it's fun.

I'm not sure what you mean by HTTP firewall. If you mean a regular 
firewall that only allows port 80, then tunnelling through is one of the 
requirements Web Socket was designed to address -- it certainly wasn't 
done for fun. If you mean an HTTP proxy, then Web Socket is explicitly 
designed to _not_ go through them.

On Sat, 19 Dec 2009, Jamie Lokier wrote:
> 
> Given WebSocket's stated goals (on this list) of:
> 
>    - Not working through HTTP proxies, including intercepting proxies.
>    - Not being HTTP compatible.
>    - Not being correctly parsable by a correct HTTP request parser.
> 
> I'm thinking it would be easier to just use port 81 and be done with it.

Unfortunately one of the other requirements is "can be used in 
environments that only have ports 80 and 443 open". Shareing port 80 with 
an HTTP server isn't the interesting case for Web Sockets, it's being 
hosted on port 443 that's the interesting case.

(I originally proposed using port 81, but when registering the port was 
told to use port 80 instead.)

On Fri, 18 Dec 2009, Justin Erenkrantz wrote:
> 
> Proxies (mainly reverse proxies) and caching are incredibly important to 
> any real scalability efforts.  I'm not aware of many high-traffic web 
> setups that don't rely upon massive amounts of front-ends.  So, any port 
> 80 traffic to any big sites is very likely to hit an hardware box (F5, 
> etc.) or a software balancer (a la mod_proxy or varnish or squid).  If 
> the current WebSockets ID is intended to *fail* in those situations, the 
> deployment story is likely to be a real non-starter...

How so? If you want to deploy a Web Socket server, then yeah, you have to 
update your scalers and so on. That doesn't seem like a shocking 
revelation, it seems obvious. Do you expect to use HTTP caching servers 
and load balancers in front of an IRC or SSH server?

> I'm curious what the makeup of this hybi@ list/WG is - how many server 
> or intermediary devs are on this?  From browsing the archives, it looks 
> like it is mostly browser/user-agent developers so far.

I can't speak for other members, but my current employer is the third 
largest server developer by active server count [1], and is also a pretty 
significant user of server-side intermediaries such as load balancers, 
routers, and the like. (At the time I started working on Web Socket, then 
called TCPConnection, I worked for Opera.)

[1] http://news.netcraft.com/archives/2010/01/07/january_2010_web_server_survey.html

On Sat, 19 Dec 2009, Jamie Lokier wrote:
>
> I'd say there are many server and application developers on the list 
> (including me), but the WebSocket protocol appears to be more driven 
> from the browser API side.  It is explicitly designed to support a 
> Javascript API, and pays little attention to issues like network 
> performance and scalability.

There's not much mention of it in the protocol, but those issues were 
considered in its development. It is likely that the balance is more 
towards the end-user and Web author side of things than is usual at the 
IETF, but having seen how complex some IETF protocols are (e.g. HTTP, 
XMPP, BEEP), I don't think that's a bad direction to go in.

If there are improvements that can be made for network performance and 
scalability while maintaining the author-friendliness of the protocol, 
please do send the feedback in. I've already discussed this protocol with 
people involved in mobile networks, large scale server-side deployments, 
small-scale server-side developers, and developers of server-side 
frameworks of various sizes, but more feedback is always welcome.

On Tue, 22 Dec 2009, Greg Wilkins wrote:
> 
> But now that you have been encouraged to use port 80, then you need to 
> play by the existing rules on port 80 - up until the time the upgrade 
> response is sent. After that, you can go crazy with the cheeze-whiz on 
> new protocol and any intermediary that does pass the upgrade, but does 
> not handle the subsequent traffic is in the wrong.
> 
> But prior to the upgrade response, you are in HTTP and should be 
> governed by RFC2616 and not just pretend HTTP.

The client is required to send something that is HTTP-compliant. There's 
no pretense here, it's really HTTP compliant. It's over-constrained 
relative to what HTTP allows, but that's fine, because it's a Web Socket 
client, not an HTTP client, so there's no difficulty in implementing such 
extra requirements.

On the server side, if it's a Web Socket server, then HTTP is irrelevant, 
and again, the extra requirements don't matter. It can just send the Web 
Socket response (which happens to look like HTTP, but that's mostly just 
for consistency with the request). If it's an HTTP server, then Web Socket 
doesn't apply.

So I really don't understand what it is you think needs to be changed. 
You've said things like the headers should be allowed to be in any 
order... but the client is a Web Socket client, so why would we 
arbitrarily say that the client could send back headers in a different 
order? It wouldn't help anyone, since the client isn't an HTTP client, and 
is unlikely to share any of the relevant code. (Code for some of the 
authentication headers could be shared, but those _are_ allowed in any 
order, in their spot in the request.) Similarly, the server, when parsing 
the headers in "HTTP" mode, is unaffected by the order -- and indeed, the 
Web Socket spec doesn't require _anything_ from the server in terms of 
parsing the client request. You can completely ignore it for all the spec 
cares. All that matters is that you send back a specific handshake. But if 
you're sending back the handshake, then you're a Web Socket server, so why 
do we need to follow HTTP rules? We've already established the client is a 
Web Socket client, so what on earth is the point of using HTTP rules?

> > It's only through three years of responding to feedback that we've 
> > reached this point, and I've done my best to ensure that the handshake 
> > really is compatible with HTTP
> 
> Why "compatible with HTTP"?  Why not just be real HTTP prior to the 
> upgrade?

I really don't understand the practical difference. Are you suggesting 
that a Web Socket client should look around at what HTTP connections are 
already open to the same port and if there is one, just do an Upgrade 
half-way through the connection? That sounds like a nightmare waiting to 
happen. What practical real problem would supporting that solve?

> This list and the squid list and other forums are full of people raising 
> use-cases that are not supported.  This thread was started by a post 
> about a C HTTP stack that had difficulty with the "compatible HTTP", 
> I've posted similar issues with the Jetty implementation.

It seems pretty obvious that trying to jam a two-way protocol into a 
server designed for a request-response protocol is going to be non-trivial 
_regardless_ of what the protocol looks like. Making it possible to 
upgrade half-way through a connection or requiring that the server support 
even more headers or making it possible to hide the Upgrade request in the 
trailer headers of a chunked request or something equally asinine simply 
isn't going to make it easier.

> The squid list shows how a caching proxy is having problems with just 
> "compatibility"

A caching proxy makes as much sense with Web Socket as with, say, SSH.

> and there have been plenty of other use-cases listed about load 
> balancers, SSL offload, etc. etc.

As far as I can tell, these issues have been resolved.

On Sat, 19 Dec 2009, Greg Wilkins wrote:
> Jamie Lokier wrote:
> > For protocols which don't look like HTTP, you mainly do it because 
> > sometimes TCP port 80 is the only available outgoing port in 
> > firewalled environments.  Ironically, there is often an intercepting 
> > proxy in such environments, so it won't actually work.
> 
> In countries with repressive regimes that are against free speech ( eg. 
> Australia), there will always be a proxy on port 80 making sure that you 
> don't read about religions (eg falun gong) that offend our major trading 
> partners (eg china) etc.
> 
> So websocket is specified to not work at all in Australia. Of course it 
> probably will work - but not because it is specified to do so, but 
> because the proxies just happen to be implemented in certain ways.  
> Happen stance is not a great basis for a protocol.

Can you use TLS from Australia on port 443? If you can, then Web Socket 
should work fine. Port 80 really isn't the interesting story.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Justin Erenkrantz <[email-masked]>
Date: Sun, 31 Jan 2010 08:25:42 -0800

> for consistency with the request). If it's an HTTP server, then Web Socket

Given that the drafts mandate that WebSocket share a port with HTTP,
it is simply not possible to know ahead of time what the incoming
connections are going to be - unless the deployment uses separate IPs
which is the end result of these rules.

However, no reasonable deployment is going to give separate IPs to WS
versus HTTP - so, server-side implementors are left with two choices:
in the case of Jetty, we've seen them go through a whole bunch of code
contortions to implement the strict conformance rules or, what would
have to happen with httpd (because the hacks required would simply be
vetoed and it goes against the whole async server philosophy) - just
ignore them altogether.  Neither places WS on an immediate
good-feeling footing with server-side developers.

Since you brought up your employer and their "market share", I'm very
very willing to bet Google isn't going to use duplicate IP ranges just
for WS vs HTTP either.  They would have to teach their custom
front-ends how to share and route WS *and* HTTP requests as well over
the same port.  So, your colleagues are going to run into this issue
as well.  Perhaps out of courtesy, they went through the same hell
that Jetty went through - but, again, I can't go back to
[email-masked] with a straight face and hack up the overall
architecture just for this non-feature.  The conformance that is
apparently so important would be sacrificed from day one.

As such, the draft should really make it as painless as possible to
share ports.  Either drop the port 80 requirement or drop the overly
strict conformance requirements: you simply can't have it both ways
and expect any serious buy-in from server developers.  (And, really,
altering ports isn't much better, but at least it's philosophically
cleaner.)  I realize that most client devs don't care about this for
the reasons Maciej pointed out (alas, the Serf client framework *does*
care much for the same reasons as httpd - but it obviously doesn't
have the market share of WHATWG's participants - so I don't expect
anyone to care), but this is such a ridiculously large pain point for
servers that is being constantly belittled by the person in charge of
the drafts that it makes me question even continuing to bother
providing feedback at all.  -- justin

---

From: Pieter Hintjens <[email-masked]>
Date: Sun, 31 Jan 2010 21:19:32 +0100

> _possible_ to parse the header with an HTTP stack, if not necessarily

Do you not understand the impact of breaking (cheerfully or not) a
30-year standard respected by the entire Internet?

Post 80 is not shared by protocols.  Port 80 IS HTTP by definition, by
contract.  When you send non-HTTP stuff on port 80 you are breaking
the contract.  You are in effect creating an out-law protocol, backed
by the weight of a massive company, and this breaking of an old and
very important contract, by force, is what is creating the backlash on
this (very polite IMO) group.

You have two sustainable choices: use another port, or conform to port
80's contract, i.e. use valid HTTP until you can escape into
unregulated space.

Your current choice (to use port 80 with the excuse "IANA told me to",
and then to ignore the existing contract on that port) is going to
create continued resentment, and eventually a backlash against your
spec.

There are other serious problems in the high-handed approach you are
taking but this is the most serious.  If you switch to another port OR
if you respect HTTP until you come into contractless space, you can do
whatever madness you wish.

Ignore these contracts, and the repeated advice given on this list, at
your own peril, Ian.  Even Google cannot fight that amount of history
(and I doubt it seriously wants to).

- Pieter

---

From: Pieter Hintjens <[email-masked]>
Date: Sun, 31 Jan 2010 21:26:30 +0100

> 30-year standard respected by the entire Internet?

For clarity, that standard is that one port = one protocol, that the
port defines a contract, and that clients and servers can co-exist by
sticking to the contract, without exception.  And the reason for this
standard is to ensure freedom of choice, and it is this freedom that
creates competition between vendors, and thus over time lowers costs
and improves quality.

By creating an extended subset of port 80, you are going in the
opposite direction.

-Pieter

---

From: <[email-masked]>
Date: Sun, 31 Jan 2010 21:27:56 +0000

I see an analogy here with UDP Lite, an enhancement to UDP that was
intended to be seamless, but eventually wound up getting its own
protocol number instead of 'upgrading' UDP. (Since existing stacks
relied on the existing 'redundant' UDP segment length, rather than the
lower IP datagram length.)

In the UDP Lite case, valid implementation concerns eventually led to
a new protocol number being assigned, rather defeating the 'upgrade'
ambitions of the original proposal, and UDP Lite has died a quiet
death for a number of reasons. I can see valid implementation concerns
leading to Web Socket being given a new port number.

Appealing to contract doesn't cut it. Detailing practical
implementation concerns with the upgrade sequence and the difficulty
of making it work reliably across implementations will have far,
far more effect in getting Web Socket off port 80.

We already have BEEP for framing over TCP and to avoid
head-of-line blocking. What would be wrong with that, apart
from the fact that BEEP is already dead?

L.

On 31 Jan 2010, at 20:19, Pieter Hintjens wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 1 Feb 2010 01:21:07 +0000

> from the fact that BEEP is already dead?

There are a few technical issues with BEEP, discussed several months
ago on the hybi list (consulte the archives).  It's usable but
over-complex in some respects and sub-optimal in others.  Nonetheless
there are some good things to learn from BEEP.

Is BEEP really dead? It had quite a long claimed list of users when I
looked last year.

Note that issues like multi-destination head-of-line blocking are not
addressed by WebSocket.  The current design expects individual
applications layered over WebSocket to deal with those issues using
their own application-specific protocol, where relevant.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 1 Feb 2010 01:29:14 +0000

Pieter Hintjens wrote:
> contract.

It is a fact that internet access is only granted over ports 80
and/or 443 at some locations.

This is why WebSocket uses those.  It is for that practical reason,
not from a desire to break the port convention.  Thus there is no
point complaining on port convention grounds.

An earlier version of WebSocket proposed port 81, but that was changed to 80.

I do wonder if those sites only allowing port 80 all run intercepting
proxies on port 80 which would prevent WebSocket using it, so that it might
as well use port 81 anyway. Anybody know?

-- Jamie

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 31 Jan 2010 19:19:09 -0800

> By creating an extended subset of port 80, you are going in the

What are the RFC2616 requirements on HTTP upgrade? Does it limit the set of criteria that an upgrade protocol may use to reject an upgrade request or response? I didn't see such a requirement. So I think WebSocket does satisfy the contract for port 80, though admittedly in a way that may be inconvenient for some deployed software.

Regards,
Maciej

---

From: Justin Erenkrantz <[email-masked]>
Date: Sun, 31 Jan 2010 20:24:11 -0800

On Sun, Jan 31, 2010 at 7:19 PM, Maciej Stachowiak <[email-masked]> wrote:
> What are the RFC2616 requirements on HTTP upgrade?

If the server accepts the Upgrade request, it will send back a 101 in
an HTTP/1.1-formatted response and then *after* the blank line
terminating the response, the new protocol is in effect.  So, in
essence, you have one HTTP/1.1 request and one HTTP/1.1 response, a
blank line (CRLF), and then all bets are off.  (See 10.1.2 of RFC
2616.)

> Does it limit the set of criteria that an upgrade protocol may use to reject an upgrade request or response? I didn't see such a requirement. So I think WebSocket does satisfy the contract for port 80, though admittedly in a way that may be inconvenient for some deployed software.

No, because the drafts mandate "specific opaque bytes" rather than
anything that looks like an HTTP/1.1 request.  -- justin

---

From: SM <[email-masked]>
Date: Sun, 31 Jan 2010 21:45:02 -0800

Hi Jamie,
>point complaining on port convention grounds.

I understand your point.  That will still not be viewed as a good 
reason to tunnel everything over port 80 or port 443.

>An earlier version of WebSocket proposed port 81, but that was changed to 80.

The registration request was rejected.  If the protocol requires a 
port to be allocated, there should be proper justification for the 
request.  It is unlikely that two ports will be assigned as the 
practice of having a different port number for the secure version of 
a protocol is discouraged.

Regards,
-sm

---

From: Mridul Muralidharan <[email-masked]>
Date: Mon, 1 Feb 2010 11:51:56 +0530 (IST)

For sharing multiple logical channels over a single underlying channel, I had suggested BEEP [1] to the list initially.
For a more http compliant server side push (simulated ofcourse), there is XEP 124 [2] which uses a variant of more robust version of long poll - which has been used quite successfully in xmpp space : with the caveat that, one of clients connections would need to be blocked at the server (within timelimits) for notifications.
While implementing xmpp on top of http, we had more practical reasons why we chose xep 124 (it was a fledging standard when we looked at it initially), which was how well you can interact with intermediaries which you have no control over : which is what led to not pursuing a comet channel approach (reliability issues, proxy caching of response (non-compliant at times), etc). We can wish away a lot of these issues, but for real world customer deployments - you will have to address them anyway.

I am not sure if proper due diligence was done on these, but I assume the group has - since I have not followed the discussions of the past couple of months.

Regards,
Mridul

[1] http://beepcore.org/
[2] http://xmpp.org/extensions/xep-0124.html

----- Original Message ----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Mon, 1 February, 2010 2:57:56 AM
> Subject: Re: [hybi] Web sockets and existing HTTP stacks
> 
> > On Sun, Jan 31, 2010 at 10:22 AM, Ian Hickson wrote:
> > 

      Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 31 Jan 2010 22:31:48 -0800

Consolidating replies to multiple messages...

> blank line (CRLF), and then all bets are off.  (See 10.1.2 of RFC

Sure, but I don't see a limit on the reasons a client or server could reject an upgrade attempt, including looking at details of the HTTP header that HTTP itself does not care about.

> anything that looks like an HTTP/1.1 request. 

The spec requires sending requests and responses that are valid HTTP syntax. It also requires rejecting some upgrade requests or responses that would also be valid (and equivalent) at the HTTP level. This is a mild layering violation, but I don't see how it "breaks the contract".

In any case, I'm more interested in what is a practical problem for implementations, than theoretical purity. 

On Jan 31, 2010, at 8:05 PM, Greg Wilkins wrote:

> Maciej Stachowiak wrote:
> 
>> This reduces the burden on server implementors. 
> 
> It actually increases the burden.   If there are only a few fixed headers then it's easier
> to correctly order and format them.   With arbitrary headers we have to allow existing mechanisms
> add/examine their headers, but then make sure they've not actually broken any websocket
> restrictions.

Would a strict status line requirement, followed by headers that can have any order or capitalization, be reasonable?

> 
>> But it also seems to reduce the security benefit. In particular, the part of the handshake where
>> the server echoes back the origin is not part of the hardcoded handshake but rather just a normal header. In light of this I'm not sure the fixed header is pulling its weight.
>> It does probably add some amount of protection for resources that suffer header injection attacks - to fake the WebSocket handshake you'd have to inject before the real HTTP
>> response header, and could not rely on injecting in the middle of a response. 
> 
> But then the sentinel framing of websocket is completely vulnerable to injection attacks.
> All websocket endpoints will have to validate that utf-8 data given to them really is utf-8 data.

I believe the only component that absolute has to check for violations of the sentinel framing to maintain security is the browser - it needs to prevent script code running in the browser from doing shady things to an existing connection, so it can't let scripts inject a sentinel. If your threat model is non-browser code, that presumably lacks any user credentials you are using for access control, so the risk is limited. If you are thinking about an out-of-browser client that does have the user's credentials, then the client can already send any valid message it chooses, so there's no motive to try to abuse the protocol framing to inject messages.

For robustness, of course, all parties should check both incoming and outgoing framing for correctness.

> And I still don't get the protection it is giving?  Can you describe a concrete example
> of an attack that could happen if arbitrary ordering of headers?

I should note that requiring a hardcoded format is not my idea, and I'm not even sure it's a good idea, so I am probably not the best person to give a full justification. However, my understanding is that the threat models that this problem tries to address are:

1) Ordinary HTTP server has a header injection vulnerability. Hostile code in the browser attempts to get unauthorized access to HTTP resources with the user's credentials, via WebSocket.
   => Header injection vulnerabilities are most likely to occur in the middle of the headers, not before the status line, which is why a hardcoded prefix provides some defense. (But I'm not sure status line plus two fixed headers is any stronger than just a requirement on the status line.)

2) Non-HTTP network service gives a connecting party some limited control over what it echos back. If an attacker can, through normal use of WebSocket, get it to produce any response that looks like a valid WebSocket handshake, then they may be able to get unauthorized access from the browser.
   => In general, the less flexible the handshake format, the harder it is to find a protocol you can abuse this way. However, I think the key defense for this kind of thing is some kind of challenge/response where the response echoed back is based on the request, but in a way that does not just consist of literally echoing back some of the characters.

My own judgment would be that for both of these threat models, requiring a specific status line but allowing the Connection and Upgrade headers to appear anywhere in the response headers and with any capitalization would provide about the same level of defense. I can also ask some security experts I know to evaluate this reasoning.

On Jan 31, 2010, at 8:19 PM, Justin Erenkrantz wrote:

> On Sun, Jan 31, 2010 at 7:08 PM, Maciej Stachowiak <[email-masked]> wrote:
> 
>> But it also seems to reduce the security benefit.
> 
> I've noticed a few mentions so far of "security" as a key driver for
> having an hardcoded initialization sequence, but I can't just envision
> the tangible security benefits from mandating this.
> 
> So, what is the threat model that this mechanism is trying to prevent?

See above. I believe the mechanism is intended to reduce the attack surface that WebSocket creates in existing HTTP and non-HTTP Web services. I am not sure I agree with the exact tradeoff made, but I can certainly see the logic. Though the client sending a nonce and the server responding with a particular hash of that nonce would be even more effective at protecting existing servers than anything that only includes fixed components and excerpts of the request text.

> How do these threats differ from other attacks against HTTP?  --

Existing browser mechanisms to send HTTP requests can be subject to superficially similar attacks:

A) Form submission can be used to send HTTP requests to non-HTTP services, whether they run on port 80 or some other port. Due to the same-origin policy, the result is not disclosed to the attacker, so these are only attacks on integrity, not confidentiality. To defend a non-HTTP service against this threat model, you need to ensure that anything with the syntax of a valid HTTP request that might be sent by a browser cannot have any side effects on your service. You don't need to worry about the risk of information disclosure in your response, though.

B) HTTP header injection attacks could be used against HTTP services, and may pose various security risks. In the case of vanilla HTTP, though, we can't mitigate this risk by forcing certain headers to be in a specific place. An example of this risk: if the attacker has hostile JS running in a browser that supports CORS, they may be able to get access to a confidential resource, if they can inject response headers "Access-Control-Allow-Credentials: true" and "Access-Control-Allow-Origin: <ORIGIN>" where <ORIGIN> is the attacker's security origin. However, this can't really be mitigated in the same way as WebSocket, and the integrity risk is somewhat lower since it's hard to use this technique to inject arbitrary additional requests.

I think WebSocket presents a somewhat different attack surface, so it's worth considering additional mitigation, but I am not sure the current  mechanism strikes quite the right balance.

For better protection with less impact on server code, I'd include a nonce in the handshake request (provided by the UA), require the status line of the response to include a particular hash of the nonce and the origin (it doesn't even have to be a cryptographically strong hash, it just needs to result in something other than literal echoing), and remove verbatim requirements from the rest of the response.

On Jan 31, 2010, at 8:05 PM, Greg Wilkins wrote:

> Maciej Stachowiak wrote:

>> OTOH just the special status line ("HTTP/1.1 101 Web Socket Protocol Handshake") guarantees this.
>> Would it be reasonable to limit the hardcoded part of the handshake to the status line?
> 
> It does not need to be expressed as hardcoded bytes.
> It can be expressed as a HTTP response with status code of 101 and
> reason of "Web Socket Protocol Handshake"

I can see why requiring exact ordering and capitalization of some of the response header fields would be a burden for server-side software that wants to plug into a general-purpose http server. Is a requirement for exact character sequence of the status line a burden in the same way? Or is this a more theoretical concern?

> Then if we ever get HTTP/1.2 or HTTP/2.0, websocket will not break!

If the client tries to upgrade an HTTP/1.1 request to WebSocket and the server gives an HTTP/1.2 or HTTP/2.0 response, then it had better break! We'll need to adjust the client side of the protocol before we can let servers respond with different versions of HTTP.

Regards,
Maciej

---

From: Mridul Muralidharan <[email-masked]>
Date: Mon, 1 Feb 2010 12:02:55 +0530 (IST)

----- Original Message ----

> From: Jamie Lokier <[email-masked]>
> To: Pieter Hintjens <[email-masked]>
> Cc: [email-masked]
> Sent: Mon, 1 February, 2010 6:59:14 AM

This is an oft-repeated argument in this list, and in some xmlrpc/WS lists - and I am not very sure I buy the argument.
There is a reason why only http is allowed by a lot of firewalls and proxies - and it is a deployment choice the customer makes : whether driven by security concerns, convention, or other - it is a conscious decision at times (not always, I admit).

The reasoning that - port 80 is not blocked, so let us tunnel protocol xyz over it, is not a very good line of reasoning: it is not an invitation for protocol designers to tunnel arbitrary protocols on top of http.
Either you send http on top of port 80, or use something else - so that a deployment has control : both in terms of security concerns, intermediaries which can be deployed, contractual validation, etc.

My 2 cents.
Regards,
Mridul

---

From: Roberto Peon <[email-masked]>
Date: Sun, 31 Jan 2010 23:40:08 -0800

I am a server developer
I do expect that if something goes over port 80, it should conform to HTTP
spec until the spec agrees that it no longer applies.
We have a significant and large population of users who have no
understanding of the underpinnings of the technology-- all they want is
their web pages to work.

If you're seriously saying that we should not acknowledge that the web is
broken over anything other than port 443 (heck, I don't even think that you
can claim that port 80 works all the time, especially if you want to use
UPGRADE, etc.), I'm interested in hearing about hard data that supports that
assertion.

In other words, If deployment using a new port isn't a problem, what is the
solution? Whatever it is, should it exist, I'd be happy to use it.
-=R

On Sun, Jan 31, 2010 at 10:32 PM, Mridul Muralidharan
<[email-masked]>wrote:

> This is an oft-repeated argument in this list, and in some xmlrpc/WS lists
> - and I am not very sure I buy the argument.
> There is a reason why only http is allowed by a lot of firewalls and
> proxies - and it is a deployment choice the customer makes : whether driven
> by security concerns, convention, or other - it is a conscious decision at
> times (not always, I admit).
>

At times? What percentage of web users out there know how it all works? ..
and driven by "convention" is a poor reason to do something.

>
> The reasoning that - port 80 is not blocked, so let us tunnel protocol xyz
> over it, is not a very good line of reasoning: it is not an invitation for
> protocol designers to tunnel arbitrary protocols on top of http.
> Either you send http on top of port 80, or use something else - so that a
> deployment has control : both in terms of security concerns, intermediaries
> which can be deployed, contractual validation, etc.
>

All of those things can still do the right thing over port 80. They see what
they don't like, then they can drop it.
.. and much of the difficulty in deploying anything "new" on the web today
is because of intermediaries that the user doesn't know exist (and thus
couldn't desire the presence of..)

-=R

>       Your Mail works best with the New Yahoo Optimized IE8. Get it NOW!
> http://downloads.yahoo.com/in/internetexplorer/