Re: AW: [squid-users] Invalid Reponse on Squid 3.0 and 3.1 but not 2.6

On 8/06/2012 10:28 p.m., Alexander.Eck_at_Heidelberg.de wrote:
> Thanks for your reply!
>
> Here's the header I'm receving with curl on my squid 3.1 machine:
>
> curl -0Iv http://register.dpma.de/DPMAregister/marke/experte.kopf.form
> * About to connect() to register.dpma.de port 80
> * Trying 194.59.120.150... connected
> * Connected to register.dpma.de (194.59.120.150) port 80
>> HEAD /DPMAregister/marke/experte.kopf.form HTTP/1.0
>> User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
>> Host: register.dpma.de
>> Accept: */*
>>
> < HTTP/1.1 302 Moved Temporarily
> HTTP/1.1 302 Moved Temporarily
> < Date: Fri, 08 Jun 2012 10:26:51 GMT
> Date: Fri, 08 Jun 2012 10:26:51 GMT
> < Server: Apache-Coyote/1.1
> Server: Apache-Coyote/1.1
> < X-Powered-By: Servlet 2.4; JBoss-4.3.0.GA_CP06 (build: SVNTag=JBPAPP_4_3_0_GA_CP06 date=200907141446)/JBossWeb-2.0
> X-Powered-By: Servlet 2.4; JBoss-4.3.0.GA_CP06 (build: SVNTag=JBPAPP_4_3_0_GA_CP06 date=200907141446)/JBossWeb-2.0
> < Location: http://register.dpma.de/DPMAregister/HttpSessionExpiredPage;jsessionid=3FB3BC4CB806505CE05DD64B02687D73.reg-app01
> Location: http://register.dpma.de/DPMAregister/HttpSessionExpiredPage;jsessionid=3FB3BC4CB806505CE05DD64B02687D73.reg-app01
> < Content-Type: text/plain
> Content-Type: text/plain
> < Set-Cookie: JSESSIONID=3FB3BC4CB806505CE05DD64B02687D73.reg-app01; Path=/
> Set-Cookie: JSESSIONID=3FB3BC4CB806505CE05DD64B02687D73.reg-app01; Path=/
> < Connection: close
> Connection: close
>
> * Closing connection #0
>
> But I'm not quite sure what's wrong with this header ?

That one has nothing wrong. I got a similar perfectly fine one with my
squidclient tests to see what the issue was.

When doing it from Firefox I get 4KB of Set-Cookie (in itself that is
not terrible, but there were some suspicious missing delimiters between
cookies in there).

Amos

>
> Alex
>
>
> -----Ursprüngliche Nachricht-----
> Von: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
> Gesendet: Freitag, 8. Juni 2012 11:47
> An: squid-users_at_squid-cache.org
> Betreff: Re: [squid-users] Invalid Reponse on Squid 3.0 and 3.1 but not 2.6
>
> On 8/06/2012 8:36 p.m., Alexander.Eck_at_Heidelberg.de wrote:
>> Hi everyone,
>>
>> I'm receiving an error page
>> "Invalid response"
>> When accessing a specific website.
>>
>> I'm running squid-3.0.STABLE9-1.el5 on Centos 5.7. The website is the following:
>>
>> http://register.dpma.de/DPMAregister/marke/experte
>>
>> just press the button "Recherche starten" and you will see the error page.
>>
>> Looking at the cache.log file I see no error or something.
>>
>>
>> I have another squid-2.6 on another Centos 5.7 machine. When using this the webpage is displayed correctly.
>>
>>
>> For testing purposes I upgraded my squid 2.6 to squid-3.1.14-1.el5 and tried to access the webpage again.
>> Now I'm receiving the same error page as with squid 3.0.
>> Fortunately in cache.log I'm receiving the following Warning now:
>>
>> WARNING: HTTP: Invalid Response: Bad header encountered from
>> http://register.dpma.de/DPMAregister/marke/experte.kopf.form AKA
>> register.dpma.de/DPMAregister/marke/experte.kopf.form
> What this means is that an apparently HTTP header is received from the server which violates the required HTTP syntax. It is detected on arrival before anything else happens, which is why none of your attempts at config bypasses are working.
>
>
>> I alrdy tried the following on my squid 3 .0 and 3.1:
>>
>> 1. Adding the following to squid.conf:
>> a. Acl dpma dstdomain register.dpma.de b. Request_header_access
>> Accept-Encoding allow dpma
> ==> Accept-Encoding header is allowed by default, allowing it manually as well is a no-op.
>
>> 2. Deleting the above and editing:
>> a. Acl dpma dstdomain register.dpma.de b. Cache deny dpma
> ==> Denying an object from being stored by Squid does not prevent theupstream server from generating invalid responses.
>
>
>>
>> Can anybody please help me here? I'm not sure why the webpage is displayed on 2.6 correctly, but not on 3.0 and 3.1 ?
>> My guess is that the header is corrupt, but shouldn't my first change (Request_header_access etc. ) get this working ?
> Squid-2.6 has almost no HTTP/1.1 support. All it takes is for some
> HTTP/1.1 feature which 3.x are supposed to parse and process being
> invalid syntax, but which 2.6 does not have any support for even parsing
> to detect that invalidity.
> I'm not saying that is the issue, just that its trivially possible to
> get this type of distinction without any bugs or regression actually
> being present.
>
> You need to get a copy of the headers which Squid is receiving from the
> upstream server and see what is wrong with them.
>
> Amos
Received on Fri Jun 08 2012 - 11:15:03 MDT