On 22/10/22 06:04, Grant Taylor wrote:
On 10/20/22 11:58 PM, Adam Majer wrote:
It's basically by convention now.
Sure.
Conventions change over time.
Long enough ago 3128 wasn't the conventional port for Squid.
Not just convention. AFAICT was formally registered with W3C, before
everyone went to using IETF for registrations.
Maybe, hopefully, said discussion will spark an idea in at least one
person's head and that might turn into something in 10 or 20 years.
FYI, discussion started ~30 years ago.
The problem:
For bandwidth savings HTTP/1.0 defined different URL syntax for origin
and relay/proxy requests. The form sent to an origin server lacks any
information about the authority. That was expected to be known
out-of-band by the origin itself.
HTTP/1.1 has attempted several different mechanisms to fix this over the
years. None of them has been universally accepted, so the problem
remains. The best we have is mandatory Host header which most (but sadly
not all) clients and servers use.
HTTP/2 cements that design with mandatory ":authority" pseudo-header
field. So the problem is "fixed"for native HTTP/2+ traffic. But until
HTTP/1.0 and broken HTTP/1.1 clients are all gone the issue will still
crop up.
And ... Squid still only supports HTTP/1.1 and older.
Forward proxies don't sit on regular server ports because they require
explicit config on the client.
If we're explicitly configuring the client, then what does the port
that's chosen have any influence on the explicit configuration?
More importantly the proxy hostname:port the client is opening TCP
connections to may be different from the authority-info specified in the
HTTP request message (or lack thereof). This crosses security boundaries
and involves out-of-band information sources at all three endpoints
involved in the transaction for the message semantics and protocol
negotiations to work properly.
Curl's man page is rather convenient and somewhat supportive ~> telling:
```
Using an environment variable to set the proxy has the same
effect as using the -x, --proxy option.
http_proxy [protocol://]<host>[:port]
Sets the proxy server to use for HTTP.
HTTPS_PROXY [protocol://]<host>[:port]
Sets the proxy server to use for HTTPS.
```
Notice how the `[:port]` is /optional/?
What that text does not say is that when they are omitted by the
**user** they are taken from configuration settings in the OS:
* the environment variable name provides:
- the protocol name ("http" or "HTTPS", aka plain-text or encrypted)
- the expected protocol syntax/semantics ("proxy" aka forward-proxy)
* the machine /etc/services configuration provides the default port
for the named protocol.
Attempting to use a reverse-proxy or origin server such a configuration
may work for some messages, but **will** fail due to syntax or semantic
errors on others.
Likewise NAT'ing inbound port 443 or port 80 traffic to a
forward-proxy will encounter the same types of issues - while it is
perfectly fine to do so towards a reverse-proxy or origin server.
HTH
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
