> Yes, it does mean _squidclient_ is asking in HTTP/1.1. Just like all
modern
> browsers do. Squid is required to change the version tag on outgoings
to its
> highest supported one. Which for 2.7 is HTTP/1.0. Which is where the
below
> comments come in...
<snip>
> To track and verify. The easy way is to tcpdump the traffic from
Squid to the service
Well, I dumped all port 80 traffic on the squid box to a capture file
and am looking at it with Wireshark. I see GET requests, but they do
indicate HTTP/1.1 (due to the requests being sent from a modern browser,
as you stated above), and I tested by sending a normal GET to
www.google.com and it responded back in HTTP/1.0 (which seems to
indicate squid did its job). But, I sent a GET to the OTHER site I'm
trying to work with, though, and it responded in HTTP/1.1.
Here's the kicker though.... today, when I re-tried the function that
was broken last week due to this issue -- it worked. Nothing's changed
on my end, so perhaps a coding error was realized on the other end that
was responding to requests like mine incorrectly and it was fixed.
Still though, using tcpdump, I don't see the request after it "comes
out" of squid. At the moment I'm at a loss as to how to see that. I
figured the "recrafted" request would be reflected in the tcpdump of in
and out traffic on port 80 of the squid box somewhere (and I even tried
tcpdumping squid's own port just for kicks), but how would I, using
tcpdump, see this "version tag"-changed traffic between squid and the
remote service I'm connecting to?
David
