Henrik wrote:
> On Wed, 14 Jan 2004, David Luyer wrote:
>
> > A customer of ours is complaining that they have an embedded device,
> > which is attempting to connect to a server it knows to be HTTP/1.1
> > compliant (as the device and server are from the same vendor), and
> > our transparent proxy is intercepting the connection and rejecting it
> > due to the lack of a content length header.
>
> Yes, this is because your proxy is HTTP/1.0 and this makes the assumption
> made by the application designer no longer valid.
Well, squid has some HTTP/1.1 support ... but is HTTP/1.0 in this
regard.
> Yet another reason why interception proxying is a gross violation of
> TCP/IP and should not be taken lightly.
And yet it is so useful in so many ways, not only the performance
improvement;
* fixes broken DNS lookups from dodgy modem accelerators
* fixes incompatible TCP stacks (OSX-KA9Q becomes OSX->Linux,
Linux->KA9Q, making a working TCP connection in place of a
failing one)
* fixes problems with use of satellite for internet by re-terminating
the TCP session in the middle
* provides potential for anonymization
* fixes MTU breakage in many cases (although it can cause MTU
breakage as well, if client IPs are rewritten by the L4 switch
or if MTU related ICMP is not redirected along with the TCP
packets - this can be tricky to get right)
> > Comments? The code in question is around line 3070 of client_side.c
> > (and the if statement directly above that one is also relevant).
>
> Until chunked transfer encoding is implemented Squid has no choice of
> dropping the request.
That was what I expected, unfortunately.
> What you can do is to allow accesses to the required server directly
> without interceptign their requests.
I'm attempting to establish the server IPs and will put an exception
in the Alteon when done, as long as there aren't too many distinct
server IPs involved -- otherwise I'd have to look at how much effort
to implement chunked transfer encoding.
David.
Received on Wed Jan 14 2004 - 02:17:35 MST
This archive was generated by hypermail pre-2.1.9 : Sat Jan 31 2004 - 12:00:10 MST