On Feb 1, 2010, at 11:43 PM, Roberto Peon wrote: Simple-- the proxy won't know that the response from the server is websocket specific, and may reorder things.You should not assume that the termination point (the "host") is a server. It could be a reverse proxy. In such cases, the proxy needs to treat the response as HTTP until it has been fully read and interpreted.
This response IS HTTP, so HTTP rules apply. It isn't a some random more-restrictive subset of the response rules. It is still HTTP at that point. That means that you don't get to add additional restrictions on that request. If you do, then you're creating headaches for everyone.
OK, just to clarify, are you saying that it's specifically the constraint on header ordering that is a problem? I'm trying to figure out which specific requirements are problematic and why. For example, is the requirement to have some special text in the status line acceptable?
Regards, Maciej
Now, I may kick and scream, etc. but I certainly can be convinced that the effort to change is worthwhile if the reasons are not arbitrary. What advantage do we get from requiring special behaviors from the servers/proxies in this case? I can't think of any benefits, thus my response!
-=R On Mon, Feb 1, 2010 at 10:11 PM, Maciej Stachowiak <mjs at apple.com> wrote:
On Feb 1, 2010, at 9:39 PM, Roberto Peon wrote:
On Mon, Feb 1, 2010 at 7:55 PM, Greg Wilkins <gregw at webtide.com> wrote:
Ian Hickson wrote:
> 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?
We need to follow HTTP rules because we are in a HTTP server
that has implemented the HTTP standard and until the CRLF
is sent after the 101 response, HTTP rules OK!
Ian-- I know that I'd kick scream and generally raise hell about putting that in our little proxy were it not HTTP compliant until the end of the 101 response.
The current handshake response *is* HTTP compliant, it's just that the HTTP response needs to meet some additional restrictions, or it will be rejected by the client. Those restrictions include requirements to include particular response headers (apparently not controversial), to include particular text in the status line (only mildly controversial), and to require that the first two response headers headers must be two specific ones, with an exact required order and capitalization (this appears to bug people the most and perhaps creates the most headaches inside existing server code bases).
Are these restrictions a practical problem for you? If so, which are problematic, and can you describe the concrete issue? Knowing the intensity of your response is less useful than knowing the reason for it.
Regards, Maciej
|