On 18/09/19 10:22 am, Alex Rousskov wrote: > On 9/17/19 5:02 PM, Sam Holden wrote: > >> When I have protocol=http is reports: >> 2019/09/17 20:08:55| Accepting reverse-proxy HTTP Socket connections > >> When I don't set the protocol is reports: >> 2019/09/17 20:17:38| Accepting reverse-proxy HTTPS Socket connections > >> So it seems to be following the protocol= for the incoming protocol >> rather than just the outgoing. > > Agreed. That (still) looks like a bug to me. [PROXY protocol prefix > aside], an https_port ought to expect TLS traffic, regardless of any > port tuning options, including the poorly named "protocol" option. > > FWIW, I tried to quickly figure out what is really going on in the code, > but ran out of time -- configuration parsing code does appear to > overwrite the data member used as the incoming protocol of a listening > port which makes no sense to me and contradicts documentation, but I am > probably missing something in this mess. Hopefully, somebody else can > help you triage this further. > FYI: the protocol= current behaviour is initial support for the HTTP versions where layering is not as simple as HTTP vs HTTPS. For example; ICY, Secure-HTTP, h2, HTTP/3. All these *_port things are a red herring. The initial problem was connections to the origin server using HTTPS. Connections to originserver peer do not send URL scheme, and use the settings on the cache_peer directive as the protocol layering and message framing. So the http(s)_port options should be having no input into the problem. The problem is something in the unknown cache_peer settings, or maybe a bug in the new peer selection code. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
