Hi, I've been debugging a problem with a soap app (cognos planning) which brakes when being run through our squid 3.0 proxy . >From what I've gathered so far, according to one of the developers of the cognos appplication : "We use a lot of xml/soap communication which is chunked" And according to http://www.nabble.com/POST-PUT-request-Content-Length-td17497369.html#a17501199 http 1.0 doesn't support chunked transfer-encoding My access.log shows NONE/411 4900 when the error occurs. After tcpdumping the whole session and investigating with wireshark it seems to me that the following happens 1. client performs a 'GET' in HTTP 1.1 to the proxy 2. the proxy then performs this GET against the app server, but now it's in HTTP 1.0 3. the app server replies in HTTP 1.1 which in turn squid 4. replies in HTTP 1.0 to the client. This leads me to the following theory: Considering that chunking is incompatible with http1.0 this explains why things are breaking. This seems to happen even when I'm configuring squid to bypass requests to the app server: acl bypassquid dstdomain "/usr/local/squid/etc/domainlist.bypass.squid" always_direct allow bypassquid (the relevant app server is listed in 'domainlist.bypass.squid') 2 questions: 1.: does anybody know if I'm totally off the target about those http1.0 / 1.1 GET's being performed between client / squid / app server, and if this may or may not be the reason things brake ? 2.: I thought by configuring squid to 'always_direct' sessions to the app server that squid is transparent in between the client and the app server. As of now it seems to me that, even with bypassing squid, squid fiddles with the HTTP version in the GET's being performed resulting in the application breaking. E.G. to make this work the application must be rewritten to support giving 'content length' in those GET's where squid gives a 411 Thoughts over this matter in any form is highly appreciated. regards Joar Jegleim
