Re: [squid-users] Problems with hotmail and facebook

On 12/11/10 19:20, Landy Landy wrote:
>
>
> --- On Fri, 11/12/10, Amos Jeffries<squid3_at_treenet.co.nz> wrote:
>
>> From: Amos Jeffries<squid3_at_treenet.co.nz>
>> Subject: Re: [squid-users] Problems with hotmail and facebook
>> To: squid-users_at_squid-cache.org
>> Date: Friday, November 12, 2010, 12:05 AM
>> On 12/11/10 15:44, Landy Landy
>> wrote:
>>> Amos.
>>>
>>> Thanks for your quick reply.
>>>
>>> I haven't tried a newer version yet. The problem
>> started two days ago and I've been using that version for
>> over a year now and it worked well.
>>>
>>> --- On Thu, 11/11/10, Amos Jeffries wrote:
>>>
>>>> From: Amos Jeffries
>>>> On 12/11/10 15:11, Landy Landy
>>>> wrote:
>>>>> Hello.
>>>>>
>>>>> Our network is experiencing problems loading
>> or
>>>> accessing facebook and hotmail inbox and others
>> when I use
>>>> squid. I am using:
>>>>>
>>>>> I use google's public dns and our local isp
>>>> provider's.
>>>>>
>>>>> I tried to login to my hotmail account and got
>> this:
>>>>>
>>>>> Squid Cache: Version 3.0.STABLE24
>>>>> configure options:
>> '--prefix=/usr/local/squid'
>>>> '--sysconfdir=/etc/squid' '--enable-delay-pools'
>>>> '--enable-kill-parent-hack' '--disable-htcp'
>>>> '--enable-default-err-language=Spanish'
>>>> '--enable-linux-netfilter'
>> '--disable-ident-lookups'
>>>> '--localstatedir=/var/log/squid3.1'
>> '--enable-stacktraces'
>>>> '--with-default-user=proxy' '--with-large-files'
>>>> '--enable-icap-client' '--enable-async-io'
>>>> '--enable-storeio=aufs'
>> '--enable-removal-policies=heap,lru'
>>>> '--with-maxfd=32768'
>>>>>
>>>>> When I try accessing these pages without
>> having to
>>>> pass through squid everything works fine.
>>>>>
>>>>> Does anyone has an idea of what can be causing
>> this?
>>>>
>>>> Could you give any details about what the problems
>> actually
>>>> are please?
>>>
>>> Noticed that hotmail sometimes just hangs after
>> providing the username and password. People started calling
>> today and are driving me crazy.
>>>
>>> Also today I noticed this (Response not valid) when
>> replying to a thread on dslreports.org:
>>>
>>> ////////////////////////////////////
>>>
>>> Mientras se intentaba procesar la petición:
>>>
>>> POST /speak/wisp?enc=L2ZvcnVtL3dpc3A%3D;really
>> HTTP/1.1
>>> Host: www.dslreports.com
>>> Connection: keep-alive
>>> Referer: http://www.dslreports.com/speak/wisp?enc=L2ZvcnVtL3dpc3A%3D
>>> Content-Length: 2580
>>> Cache-Control: max-age=0
>>> Origin: http://www.dslreports.com
>>> Pragma: no-cache
>>> Content-Type: multipart/form-data;
>> boundary=----WebKitFormBoundarynmpKtsJY1cReuJwT
>>> Accept:
>> application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>>> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US)
>> AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.44
>> Safari/534.7
>>> Accept-Encoding: gzip,deflate,sdch
>>> Accept-Language: en-US,en;q=0.8
>>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
>>> Cookie:
>> __utmz=260971928.1285198857.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none);
>> __utma=260971928.458537925.1285198857.1285422374.1285465733.3;
>> dsl=6402462798:1587616; bbruid=1587616
>>>
>>> Ha ocurrido el siguiente problema:
>>>
>>> Respuesta no válida.
>>>
>>> El mensaje de Respuesta HTTP recibido del servidor
>> contactado no pudo ser entendido o tenía alguna
>> malformación. Por favor contacte al operador del sitio web.
>> Quizas su administrador del caché pueda darle a Ud. más
>> detalles acerca de la naturaleza exacta del problema en caso
>> de ser necesario.
>>>
>>> Su administrador del caché es optimumwireless_at_hotmail.com.
>>>
>>> ////////////////////////////////////
>>>
>>> Things are not as they used to be. I checked the
>> cache.log file and can't find anything there. What do you
>> recommend me to do?
>>>
>>
>> The POST is requesting "sdch" (aka binary diff encoding)
>> responses. If
>> you or any other proxy along that supply path are doing
>> anything with
>> ICAP besides straight AV scanning that could be corrupting
>> the diffs.
>>
>> The problem is in the response to that POST. The newer
>> 3.1.9 logs what
>> the problems is at debug level 1 ("debug_options ALL,1")
>> including the
>> URL for tracking.
>>
>> With that info you can drill down into the oprocessing are
>> or a tcpdump
>> log and find out what the response actually is.
>>
> Amos,
> As I mentioned earlier, I noticed the problem happen on website running AJAX code. I don't know if it makes sense but, hotmail, yahoo, and facebook all use ajax... and by the way 3.1.9 hasn't really change anything.

I know. The mechanism used to make the requests does not affect the
debugging process. They are all just HTTP traffic by the time it reaches
Squid.
  Since 3.1 has not fixed it I suggest you take advantage of its
slightly better debug output to help track down the problem. Then if the
speed is an issue revert to 3.0 to use the workaround found.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.9
   Beta testers wanted for 3.2.0.3