On 2022-11-02 09:03, Grant Taylor wrote:
On 11/1/22 1:24 PM, squid3 wrote:
No I meant W3C. Back in the before times things were a bit messy.
Hum. I have more questions than answers. I'm not aware of W3C ever
assigning ports. I thought it was /always/ IANA.
Indeed, thus we cannot register it with IEFT/IANA now. The IANA
http-alt port would probably be best if we did go official.
ACK
You see my point I hope. A gateway proxy that returns an error to
*every* request is not very good.
Except it's not "/ever/ /request/" It's "/every/ /request/ /of/ /a/
/specific/ /type/" where type is an HTTP version.
No, you cropped my use-case description. It specified a client which was
*unaware* that it was talking to a forward-proxy. Such a client will
send requests that only a reverse-proxy or origin server can handle
properly - because they have explicit special configuration to do so.
In all proxying cases there is special configuration somewhere. For
forward-proxy it is in the client (or its OS so-called "default"), for
reverse-proxy it is in the proxy, for interception-proxy it is in both
the network and the proxy.
What does CloudFlare or any of the other big proxy services or even
other proxy applications do if you send them an HTTP/1.0 or even
HTTP/0.9 request without the associated Host: header?
The working ones deliver an HTTP/1.1 302 redirect to their companies
homepage if the request came from outside the company LAN. If the
request came from an administrators machine it may respond with stats
data about the node being probed.
There is no "configured proxy" for this use-case.
Those are the two most/extremely common instances of the problematic
use-cases. All implicit use of proxy (or gateway) have the same issue.
How common is the (network) transparent / intercepting / implicit use
of Squid (or any proxy for that matter)?
All of the installs that I've worked on (both as a user and as an
administrator) have been explicit / non-transparent.
Almost all the installs I have worked on had interception as part of
their configuration. It is officially recommended to include
interception as a backup to explicit forward-proxy for networks needing
full traffic control and/or monitoring.
I take it from your statement you have not worked on networks like
web-cafes, airports, schools, hospitals, public shopping malls who all
use captive portal systems, or high-security institutions capturing
traffic for personnel activity audits.
There are also at least a half dozen nation states with national
firewalls doing traffic monitoring and censorship. At least 3 of the
ones I know of use Squid's for the HTTP portion.
I think you are getting stuck with the subtle difference between "use
for case X" and "use by default".
ANY port number can be used for *some* use-case(s).
Sure.
"by default" has to work for *all* use-cases.
I disagree.
ACK. That is you. I am coming at this from the maintainer viewpoint
where the entire community's needs have to be balanced.
Note that you are now having to add a non-default port "8080" and path
"/" to the URL to make it valid/accepted by the Browser.
You were already specifying the non-default-http port via the
"http-alt://" scheme in your example.
And you were specifying the non-default-'http-alt' port via the
"http://"; scheme in yours.
Either way these are two different HTTP syntax with different "default
port" values.
An agent supporting the http:// URL treats it as a request for some
resource at the HTTP origin server indicated by the URL authority part
or Host header.
An agent supporting the http-alt:// URL treats it as a request to
forward-proxy the request-target specified in the URL query segment,
using the upstream proxy indicated by the URL authority part or Host
header.
Clients speaking HTTP origin-form (the http:// scheme) are not
permitted to request tunnels or equivalent gateway services. They can
only ask for resource representations.
I question the veracity of that. Mostly around said client's use of an
explicit proxy.
It is clear side-effect of the fact that tunnels cannot be opened by
requesting an origin-form URL (eg "/index.html"). They require an
authority-form URI (eg "example.com:80").
See https://www.rfc-editor.org/rfc/rfc9110.html#name-intermediaries for
definitions of intermediary and role scopes.
Note that it explicitly says (requires) absolute-URI for "proxy" (aka
forward-proxy) intermediaries. Clients do not speak origin-form to
explicit proxies.
[yes I know the first paragraph says an intermediary may switch
behaviour based on just the request, that is for HTTP/2+. Squid being
1.1 is more restricted by the legacy issues].
Port is just a number, it can be anything *IF* it is made explicit.
The scheme determines what protocol syntax is being spoken and thus
what restrictions and/or requirements are.
... and so the protocol for talking to a webcache service is
http-alt://.
Whose default port is not 80 nor 443 for all the same reasons why
Squid default listening port is 3128.
If we wanted to we could easily switch Squid default port to
http-alt/8080 without causing technical issues. But it would be
annoying to update all the existing documentation around the Internet,
so not worth the effort changing now.
Ditto. Though the legacy install base has a long long long tail. 26
years after HTTP/1.0 came out and HTTP/0.9 still has use-cases alive.
Where is HTTP/0.9 still being used?
The ones I am aware of are:
* HTTP software testing and development
* IoT sensor polling
* printer network bootstrapping
* manufacturing controller management
* network stability monitoring systems
Decreasing, but still a potentially significant amount of traffic seen
by Squid in general.
Can you, or anyone else, quantify what "a potentially significant
amount of traffic" is?
I doubt anyone can quantify it accurately. But worldwide use of HTTP/1.1
is also dropping, and at a faster rate than 0.9/1.0 right now as the
more efficient HTTP/2+ expand.
Do these cases *really* /need/ to be covered by the /default/
configuration? Or can they be addressed by a variation from the
default configuration?
HTTP/1.1 specification requires semantic compatibility. So long as 1.1
is still a thing the older versions are likely to remain as well.
Undesirable as that may be.
Cheers
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
