[Guy Harris <gharris@xxxxxxxxx>]

Vicky Rode wrote:

> in-line:

Yes, that's the default, at least amongst us UN*X weenies; top-posting 
is the exception.

> At least based on what I've seen, http:// and Referer http:// headers
> came up consistently when using split proxy such as google web
> accelerator. The outgoing request had a combination of http:// and
> Referer http://.

Referer: headers, according to RFC 2616, specify "the address (URI) of 
the resource from which the Request-URI was obtained"; that has nothing 
to do with proxying.  Perhaps there exist *some* proxies that do things 
with Referer: headers, but I don't think any of the NetCache appliances 
to which I referred above do.

Referer: headers are *supposed* to contain full URIs, not just a path. 
The fact that they start with http:// shouldn't be a surprise, although 
it could start with https:// or ftp:// or....

I can't speak for what the Google Web Accelerator does, but, from a 
quick look at Google's pages talking about it, it's not a "transparent 
proxy" in the sense I used - a "transparent proxy" in that sense is a 
machine that intercepts HTTP (and possibly other) requests before 
they're passed to the origin server, and proxies them, perhaps doing 
caching (or other operations).

Just because the Google Web Accelerator happens to pass a complete URL 
in a GET header (I'm assuming that's what you mean by "in the first 
line, they use the complete URL of the resource being requested"), that 
doesn't mean that a request from an ordinary browser that doesn't even 
know it's talking to a proxy will magically have http://{origin server}/ 
inserted in front of the path in a GET request.