Roberto Peon wrote:
On Tue, Feb 2, 2010 at 5:25 PM, Maciej Stachowiak <mjs at apple.com <mailto:mjs at apple.com>> wrote: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? Having some required header ordering is a problem.As for special text in the status line, I'd have to examine the spec again to be sure-- if proxies have the ability to drop the status text (the third part of the first line of the HTTP response, which I'm assuming we're talking about here), then it shouldn't be relied upon....
I don't think HTTP specifies this. As Status-Phrase is just informational, I wouldn't surprised when it happened, or when it was rewritten. I'm pretty sure that there are server frameworks where it can't easily be set.
Anyway: if another line of defense is added (and that's how I understand Maciej's proposal), is there still a point to insist on the exact Status-Phrase?
Best regards, Julian
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.