[squid-users] FW: Encrypted browser-Squid connection errors

[Grant Taylor]

On 11/1/22 1:24 PM, squid3 at treenet.co.nz 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.

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?

> 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.

> 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.

> 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.

> 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.

> 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?

> 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?

Do these cases *really* /need/ to be covered by the /default/ 
configuration?  Or can they be addressed by a variation from the default 
configuration?

> Ah, if you have been treating it like an irrelevant elephant that is 
> your confusion. The "but not always" is a critical detail in the puzzle 
> - its side-effects are the answer to your initial question of *why* 
> Squid defaults to X instead of 80/443.

I have no problems using non-default for the "but not always" 
configurations.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20221101/95fc3eb8/attachment.bin>