On 10/30/22 6:59 AM, squid3@xxxxxxxxxxxxx wrote:
Duane W. would be the best one to ask about the details.What I know is that some 10-12 years ago I discovered an message by Duane mentioning that W3C had (given or accepted) port 3128 for Squid use. I've checked the squid-cache archives and not seeing the message.Right now it looks like the W3C changed their systems and only track the standards documents. So I cannot reference their (outdated?) protocol registry :-{ . Also checked the squid-cache archives and not finding it email history. Sorry.
Did you by chance mean IANA? I looked and 3128 is registered to something other than Squid. Nor did their search bring anything up for Squid.
I mean "authority" as used by HTTP specification, which refers to https://www.rfc-editor.org/rfc/rfc3986#section-3.2Yes exactly. That is the source of the problem, perpetuated by the need to retain on-wire byte/octet backward compatibility until HTTP/2 changed to binary format.Consider what the proxy has to do when (not if) the IP:port being connected to are that proxy's (eg localhost:80) and the URL is only a path ("/") on an origin server somewhere else. Does the "GET / HTTP/1.0" mean "http://example.com/"; or "http://example.net/"; ?
I would hope that it would return an error page, much like Squid does when it can't resolve a domain name or the connection times out.
The key point is that the proxy host:port and the origin host:port are two different authority and only the origin may be passed along in the URL (or URL+Host header).
Agreed.
When the client uses port 80 and 443 thinking they are origin services it is *required* (per https://www.rfc-editor.org/rfc/rfc9112.html#name-origin-form) to omit the real origins info. Enter problems.
Why would a client (worth it's disk space) ever conflate the value of it's configured proxy as the origin server?
I can see a potential for confusion when using (network) transparent / intercepting proxies.
I refer to all the many ways the clients may be explicitly or implicitly configured to be aware that it is talking to a proxy - such that it explicitly avoids sending the problematic origin-form URLs.
ACK
The defaults though are tuned for origin server (or reverse-proxy) direct contact.
I don't see how that precludes their use for (forward) proxy servers.
No Browser I know supports "http-alt://proxy.example.com?http://origin.example.net/index.html"; URLs.
But I bet that many browsers would support: http://proxy.example.com:8080/?http://origin.example.net/index.htmlAlso, I'm talking about "http://"; and "https://"; using their default ports of 80 & 443.
... "at your own risk" they technically might be. So long as you only receive one of the three types of syntax there - port 80/443 being officially registered for origin / reverse-proxy syntax.
I've been using them without any known problem for multiple years across multiple platforms, clients, and versions thereof. So I'll keep using it at my own risk.
It is based on experience. Squid used to be a lot more lenient and tried for decades to do the syntax auto-detection. The path from that to separate ports is littered with CVEs. Most notably the curse that keeps on giving: CVE-2009-0801, which is just the trigger issue for a whole nest of bad side effects.
I wonder how much of that problematic history was related to HTTP/0.9 vs HTTP/1.0 vs HTTP/1.1 clients.
I similarly wonder how much HTTP/1.0, or even HTTP/0.9, protocol is used these days.
Also, there is the elephant in the room of we're talking about a proxy server which is frequently, but not always, on a dedicated system or IP. As such, I have no problem predicating the use of the HTTP(80) and HTTPS(443) ports when there is no possible chance of confusion between forward proxy roles and origin server / reverse proxy roles.
-- Grant. . . . unix || die
<<attachment: smime.p7s>>
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
