Re: AW: AW: AW: [squid-users] Troubleshooting squid: modified content

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 05 May 2009 01:33:54 +1200

Sig Pam wrote:
> Jeff,
>
> I screwed around on the debug_level variable, and found in cache.log the
> following lines:
>
> 2009/05/04 11:58:39.891| WARNING: HTTP header contains NULL characters
> {Server: 4D_v11_SQL/11.4.0
> Date: Mon, 04 May 2009 09:58:39 GMT
> Cache-Control: max-age=0, private, must-revalidate
> Connection: close
> Content-length: 365
> Content-Type: text/xml
> Expires: ue, 04 May 99 09:58:39 GMT}
> 2009/05/04 11:58:39.891| HttpMsg::parse: cannot parse isolated headers in
> 'HTTP/1.0 200 OK
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Server: 4D_v11_SQL/11.4.0
> Date: Mon, 04 May 2009 09:58:39 GMT
> Cache-Control: max-age=0, private, must-revalidate
> Connection: close
> Content-length: 365
> Content-Type: text/xml
> Expires: ue, 04 May 99 09:58:39 GMT'
> 2009/05/04 11:58:39.891| processReplyHeader: Non-HTTP-compliant header:
> 'HTTP/1.0 200 OK
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Server: 4D_v11_SQL/11.4.0
> Date: Mon, 04 May 2009 09:58:39 GMT
> Cache-Control: max-age=0, private, must-revalidate
> Connection: close
> Content-length: 365
> Content-Type: text/xml
> Expires: ue, 04 May 99 09:58:39 GMT'
> 2009/05/04 11:58:39.891| Unknown HTTP status code: 600
> 2009/05/04 11:58:39.891| InvokeHandlers: 4694974055C0D959D4D13969B82ED7E9
> 2009/05/04 11:58:39.891| StoreEntry::InvokeHandlers: checking client #0
> 2009/05/04 11:58:39.891| ctx: exit level 0
> 2009/05/04 11:58:39.891| fwdFail: ERR_INVALID_RESP "Bad Gateway"
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
> Do you believe that this is a server-side problem? A bad HTTP protocol
> implementation on that particular server?
>
> Unfortunatly, I cannot check if that also happens when trying to send tax
> reports to the officials. I'll take a month until I have the next to
> send....
>
> Peter
>

I've been wondering about some of these. It reads like Squid halting at
some binary content where there should be no binary at all.

If either of you is able to get a packet trace suitable for
ethereal/wireshark of the raw reply from that server I'll take a look at
it and see where Squid is dying.

I don't need the request or data body if thats sensitive. Only the HTTP
reply headers in full packet detail.

Thanks
Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE14
   Current Beta Squid 3.1.0.7
Received on Mon May 04 2009 - 13:34:01 MDT

This archive was generated by hypermail 2.2.0 : Mon May 04 2009 - 12:00:02 MDT