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
