[squid-users] Expect Request headers

Hello

I have some software that is producing repeated TCP_MISS/417 errors in the logs and is failing to connect to the server

I have found previous discussions that show the software is not behaving correctly to the extent that after the proxy sends back the 417 - expectation failed, the client should send the request without the header. This is not happening. A sniff of the traffic shows that after the 417 is sent back the client simply repeats the request unchanged. This repeats.

All of this is using squid 2.7STABLE3 on debian 5 (lenny).

As an aside, nothing on these proxies has changed so I am at a loss in that respect.

These proxies have a cache-peer configured. When I point the client software directly at these cache-peer hosts (which I do not control) the connection works. These proxies are squid 2.6STABLE22. With these upstream ones there may be other differences (such as OS etc) but I have no visibility to them to check).

(obfuscated) Extract of sniff while connecting as best I can do it is as follows.

The fail to connect via my proxy (squid 2.7STABLE3):

Client request:

Hypertext Transfer Protocol
    POST http://www.somehost.com/api/SomeService.svc HTTP/1.1\r\n
        Request Method: POST
        Request URI: http://www.somehost.com/api/SomeService.svc
        Request Version: HTTP/1.1
    Content-Type: text/xml; charset=utf-8\r\n
    SOAPAction: "http://tempuri.org/SomeService/GetServerSettings"\r\n
    Host: www.somehost.com\r\n
    Content-Length: 233
    Expect: 100-continue\r\n
    Proxy-Connection: Keep-Alive\r\n

Proxy response:

Hypertext Transfer Protocol
    HTTP/1.0 417 Expectation failed\r\n
        Request Version: HTTP/1.0
        Response Code: 417
    Server: squid/2.7.STABLE3\r\n
    Date: Thu, 20 Jan 2011 13:27:49 GMT\r\n
    Content-Type: text/html\r\n
    Content-Length: 1476
    Expires: Thu, 20 Jan 2011 13:27:49 GMT\r\n
    X-Squid-Error: ERR_INVALID_REQ 0\r\n
    X-Cache: MISS from my.squid.proxy\r\n
    X-Cache-Lookup: NONE from my.squid.proxy:8080\r\n
    Via: 1.0 my.squid.proxy:8080 (squid/2.7.STABLE3)\r\n
    Connection: close\r\n
    \r\n

And this simply repeats - the client sends the same request again.

Using the upstream proxy (squid 2.6 STABLE22) - it works

Client request:

Hypertext Transfer Protocol
    POST http://www.somehost.com/api/SomeService.svc HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): POST http://www.somehost.com/api/SomeService.svc HTTP/1.1\r\n]
            [Message: POST http://www.somehost.com/api/SomeService.svc HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: POST
        Request URI: http://www.somehost.com/api/SomeService.svc
        Request Version: HTTP/1.1
    Content-Type: text/xml; charset=utf-8\r\n
    SOAPAction: "http://tempuri.org/SomeService/GetServerSettings"\r\n
    Host: www.somehost.com\r\n
    Content-Length: 233\r\n
        [Content length: 233]
    Expect: 100-continue\r\n
    Proxy-Connection: Keep-Alive\r\n
    \r\n

UpstreamProxy reply:

Hypertext Transfer Protocol
    HTTP/1.0 200 OK\r\n
        [Expert Info (Chat/Sequence): HTTP/1.0 200 OK\r\n]
            [Message: HTTP/1.0 200 OK\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Version: HTTP/1.0
        Response Code: 200
    Date: Thu, 20 Jan 2011 06:17:58 GMT\r\n
    Server: Microsoft-IIS/6.0\r\n
    X-Powered-By: ASP.NET\r\n
    X-AspNet-Version: 2.0.50727\r\n
    Cache-Control: private\r\n
    Content-Type: text/xml; charset=utf-8\r\n
    Content-Length: 823\r\n
        [Content length: 823]
    X-Cache: MISS from another.upstream.proxy\r\n
    X-Cache-Lookup: MISS from another.upstream.proxy:8079\r\n
    X-Cache: MISS from the.cache.peer.proxy\r\n
    X-Cache-Lookup: MISS from the.cache.peer.proxy:8080\r\n
    Via: 1.0 another.upstream.proxy:8079 (squid/2.6.STABLE20), 1.0 the.cache.peer.proxy:8080 (squid/2.6.STABLE22)\r\n
    Proxy-Connection: keep-alive\r\n
    \r\n

Any suggestions on why the difference but more importantly how to fix would be enormously appreciated.

Many thanks

rolf.
Received on Thu Jan 20 2011 - 13:48:50 MST