Re: Hello from Mozilla

Henrik Nordstrom wrote:
> 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.

The faux-request begins with: "GET /path-bytes HTTP/1.1"
It also contains "Connection: Upgrade".

Under non-surrogate traffic if we pass the request on (current behavior
AFAICT), it's stripped as I said per the request clone function.

>
> 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.

Mea culpa.

>
>> 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.
>

For peers we already have the tricky case where admin may not set
'originserver' on web server links to trigger the un-map.
Apache et al are compliant enough for this not to break the HTTP, but
will completely break the WebSocket faux-HTTP byte-wise spec.

>> 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
>

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
   Current Beta Squid 3.1.0.9