Re: Hello from Mozilla

From: Henrik Nordstrom <henrik_at_henriknordstrom.net>
Date: Thu, 16 Jul 2009 12:51:47 +0200

ons 2009-07-15 klockan 18:39 +1200 skrev Amos Jeffries:
> Byte 5 through to the first of: two CRLF or one NULL byte. Specified as
> step 1 through 11 by the looks of it.
>
> Correctly operating:
> * MUST remove the "Upgrade: WebSocket\r\n" bytes.

Yes/No depending on the context. If a normal forward proxy sees such
request then yes, but that's outside WebSocket specification as CONNECT
is used in such case.

In a surrogate intermediary situation it's essentially up to us how we
deal with the upgrade. The operations of surrogate<->origin is outside
of HTTP specifications. Specifications only cover client<->surrogate in
such setups.

In a transparent intercepting proxy it's our responsibility to deal with
the Upgrade as appropriate. i.e. switch to tunnel mode, or declare it
not supported by removing the header. Transparent interception mode is
outside of HTTP specifications.

> * MUST add "Via: 1.1 " followed by an arbitrary length and content string.

Yes.

> * SHOULD add a Date: header (position optional, suggested to be between
> GET and Host:).

No. The Date requirement is only on responses, not requests.

> Conditionally:
> * Depending on the local network topology _sometimes_ proxies required to
> alter the section labeled "the path" in order for the request to even
> happen. Changing it from ( "/" path ) to ( "http://" hostname "/" path )

Yes, but it will get changed back to the simple /path form before the
requests hits an actual origin server.

> ** The http://hostname part MAY be removed again before passing to Server.
> Usually not.

It MUST be removed per HTTP specifications (but servers MUST accept it
if sent). Future HTTP specifications MAY be relaxed to allow
absolute-URI form to be sent in requests as well but that's future when
HTTP/1.0 servers is confirmed gone from the globe.

> To raise the extreme end of the problem:
> In HTTP a proxy MAY go so far as to sort the headers alphabetically and
> expect things to still work well.

Yes.

> The solutions you need to be looking at are:
> * using HTTP Upgrade as per the HTTP spec, with full flexibility.
> * using ports other than 80.
> * sending requests as pure binary and dropping the HTTP look-alike bits

Yes.

Regards
Henrik
Received on Thu Jul 16 2009 - 10:51:53 MDT

This archive was generated by hypermail 2.2.0 : Thu Jul 16 2009 - 12:00:05 MDT