On 10/21/22 11:30 PM, Amos Jeffries wrote:
Not just convention. AFAICT was formally registered with W3C, before everyone went to using IETF for registrations.
Please elaborate on what was formally registered. I've only seen 3128 / 3129 be the default for Squid (and a few things emulating squid). Other proxies of the time, namely Netscape's and Microsoft's counterparts, tended to use 8080.
I'd genuinely like to learn more about and understand the history / etymology / genesis of the 3128 / 3129.
FYI, discussion started ~30 years ago.
ACK
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.
I'm not entirely sure what you mean by "the authority". I'm taking it to mean the identity of the service that you are wanting content from. The Host: header comment with HTTP/1.1 is what makes me think this.
My understanding is that neither HTTP/0.9 nor HTTP/1.0 had a Host: header and that it was assumed that the IP address you were connecting to conveyed the server that you were wanting to connect to.
I have very little technical understanding of HTTP/2 as I've not needed to delve into it and it has largely just worked for me.
And ... Squid still only supports HTTP/1.1 and older.
Okay. That sort of surprises me. But I have zero knowledge to disagree.
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).
My working understanding of what the authority is seems to still work with this.
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.
I feel like the nature of web traffic tends to frequently, but not always, cross security / administrative boundaries. As such, I don't think that existence of proxies in the communications path alters things much.
Please elaborate on what out-of-band information you are describing. The most predominant thing that comes to mind, particularly with HTTP/1.1 and HTTP/2 is name resolution -- ostensibly DNS -- to identify the IP address to connect to.
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.
Ergo the use of /default/ values when values are not specified.I feel like this in a round about way supports my stance that the default ports are perfectly fine to use.
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.
I question the veracity of that statement.Sure, trying to speak contemporary protocols (HTTP/1.1 or HTTP/2) to an ancient HTTP server is not going to work.
But I believe that Squid and Apache HTTPD can be configured to perform all three roles; origin server, reverse proxy, and forward proxy.
Aside: Squid might not be a typical origin server in that you can't have it /directly/ serve /typical/ origin content. However I believe it does function as an origin server for things like Squid error pages.
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.
I believe that is entirely dependent on the capability and configuration of the forward proxy. -- I've done exactly this with Apache HTTPD. Though I've not had the (dis)pleasure of doing so with Squid.
-- Grant. . . . unix || die
<<attachment: smime.p7s>>
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
