On 2/3/23 17:06, Tom JABBER wrote:
"* After sending (to the client) an HTTP response header promising a
body, Squid has an obligation to send that promised (and available to
Squid) response body. Squid does not send it. Squid is buggy."
We definitively agree on this.
"It is possible to modify Squid to stop promising to send the cache_peer
response body (at an HTTP framing level), but it is probably better (and
easier!) to modify Squid to just generate a short error response from
scratch (instead of forwarding cache_peer response headers without a
body). Doing so will probably break some use cases, so such a change may
be officially rejected, but, even if it is, it may still work/help in
some other specific use cases."
By saying this you're suggesting I try to code this?
Sorry, I should have said "modify Squid source code". To avoid
misunderstanding, I only state that it is _possible_ to "code this". I
am not suggesting that _you_ should do it (or that you should _not_ do it).
Moreover, it is not clear to me whether generating a short error
response (instead of sending a truncated one) will solve your actual
authentication-related problem (because I do not know what that problem
is). But, FWIW, a good starting point for generating that short error
response could be Http::Tunneler::bailOnResponseError() which already
generates a short error response in the "else" clause (while trying to
forward a truncated cache_peer response in the primary "if" clause).
Or is there a possible configuration I missed ?
I do not think there is a configuration option that would make Squid
forward the CONNECT error response body from a cache peer to the client.
HTH,
Alex.
@amos
"curl itself does this even without Squid."
What do you mean ?
On 2/3/23 10:52 PM, Alex Rousskov wrote:
On 2/3/23 16:15, Amos Jeffries wrote:
On 4/02/2023 7:15 am, Alex Rousskov wrote:
On 2/3/23 10:08, Tom JABBER wrote:
As said in subject, if parent proxy returns a non 200 OK code along
with some HTML body, "child" proxy reuses parent headers, which is
already a matter of discussion, and among other headers, a
content-length > 0 while not forwarding the HTML received from parent.
cf.
https://superuser.com/questions/1765082/why-squid-reuse-headers-from-parent-but-not-the-html-body-when-not-200-ok
Would there be anyone here willing to help ?
It is a known Squid bug.
@Alex, see my response. curl itself does this even without Squid.
I believe your earlier response does not contradict mine (and does not
quite match the primary question about the error response body):
* Curl has a right to ignore the CONNECT error response body sent by
the proxy. Curl is not buggy in this respect[1]. This correct curl
behavior actually matches my assertion that browsers ignore CONNECT
error response bodies.
* After sending (to the client) an HTTP response header promising a
body, Squid has an obligation to send that promised (and available to
Squid) response body. Squid does not send it. Squid is buggy.
HTH,
Alex.
[1]: I would argue that curl is also buggy with respect to header
handling because curl stores CONNECT error response headers (e.g. when
-i option is given) as if they came from the origin server. The caller
might mistake those headers for a secure origin server response
header. However, the primary question was not about the headers.
On 2/3/23 13:15, Alex Rousskov wrote:
On 2/3/23 10:08, Tom JABBER wrote:
As said in subject, if parent proxy returns a non 200 OK code along
with some HTML body, "child" proxy reuses parent headers, which is
already a matter of discussion, and among other headers, a
content-length > 0 while not forwarding the HTML received from parent.
cf.
https://superuser.com/questions/1765082/why-squid-reuse-headers-from-parent-but-not-the-html-body-when-not-200-ok
Would there be anyone here willing to help ?
It is a known Squid bug. AFAIK, the bug does not have a simple
general-purpose fix, and there is probably relatively little demand
for fixing it because popular browsers pretty much ignore CONNECT
response headers (except for proxy authentication) and body (always?).
It is possible to modify Squid to stop promising to send the
cache_peer response body (at an HTTP framing level), but it is
probably better (and easier!) to modify Squid to just generate a
short error response from scratch (instead of forwarding cache_peer
response headers without a body). Doing so will probably break some
use cases, so such a change may be officially rejected, but, even if
it is, it may still work/help in some other specific use cases.
https://wiki.squid-cache.org/SquidFaq/AboutSquid#how-to-add-a-new-squid-feature-enhance-of-fix-something
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
