Re: hotmail and zero reply length

From: chris dent <[email protected]>
Date: Fri, 16 Jul 1999 01:31:44 -0500 (EST)

After more investigating and diddling, this problem appears to be
related to the webdav patch. I've tried the following setups with a
squid 2.2.S4 with and without the webdav patch:

redhat 6.0, linux 2.2.5, netscape 6.0 configured to proxy via
localhost squid 2.2.S1

connection is a dialup connection, the terminal server segement goes
through a serveriron which redirects to the squid described below. I
switch between the webdav and non-webdav versions.

When going to hotmail and replying to a message when pressing send,
using the webdav version I eventually get a zero length reply error,
consistently. URL there is
http://lw2fd.hotmail.msn.com/cgi-bin/compose?

When going submitting a search at
http://www.compusanet.com:80/search.asp, same deal, with webdav,
eventually get zero length reply, without, works fine.

So, I guess for now I'm going to back out the webdav patch, but I'm
happy to do some testing with a new version of the patch if it comes
available. Of the about 650,000 hits the squid took today about 1000
of them were in the webdav world.

On Thu, 15 Jul 1999, Chris Dent wrote:

>
> I'm a newbie so I feel like this must have been covered before,
> but I checked the list archives and didn't find anything
> conclusive. Thanks for any help on this that you can provide.
>
> I'm using a transparent proxy squid with a serveriron on a
> terminal server segment and experiencing problems with hotmail
> that I'm having trouble figuring out.
>
> Users, when using hotmail to reply to messages, sometimes get
> ERR_ZERO_SIZED_OBJECT and I can't seem to work around it.
>
> Based on some sniffing around it literally is that hotmail is not
> returning any data at all.
>
> A machine that doesn't go through the cache, doing the same thing
> on hotmail, at the same time (within seconds, but not _exactly_
> at the same time), experiences no difficulties.
>
> I already have hotmail.com and hotmail.msn.com in a no_cache
> list, but it is apparently not caching that is causing the
> problem, but the proxying. Making the SI not force redirection on
> the various hotmail sites could prove difficult...
>
> Any suggestions on things I can diddle to deal with this?
>
> this is squid2.2.STABLE4 with the squid-2.2.stable4.webdav_support.patch
> on redhat 5.2, linux 2.2.9
>
> The no comments no whitespace version of my config is below. The
> request_size is set that large because I had thought perhaps the
> initial reports of problems with POSTs were the size limit.
> Further access and redirection controls are done in the ipchains
> setup on the box. (I suspect my http_access controls are
> buggered, if they are please let me know, thanks).
>
> http_port 80 3128
> acl QUERY urlpath_regex cgi-bin \? cfm
> no_cache deny QUERY
> acl behave_badly url_regex "/usr/local/lib/squid/no_cache"
> no_cache deny behave_badly
> acl all src 0.0.0.0/0.0.0.0
> http_access allow all
> cache_mem 128 MB
> cache_dir /var/spool/cache 3000 16 256
> debug_options ALL,1
> request_size 5000 KB
> pconn_timeout 300 seconds
> acl all src 0.0.0.0/0.0.0.0
> acl manager proto cache_object
> acl localhost src 127.0.0.1/255.255.255.255
> acl SSL_ports port 443 563
> acl Safe_ports port 80 21 443 563 70 210 1025-65535
> acl CONNECT method CONNECT
> http_access allow manager localhost
> http_access deny manager
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localhost
> http_access deny all
> icp_access allow all
> miss_access allow all
> cache_effective_user squid
> cache_effective_group squid
> httpd_accel_host virtual
> httpd_accel_port 80
> httpd_accel_with_proxy on
> httpd_accel_uses_host_header on
> logfile_rotate 0
> icon_directory /usr/lib/squid/icons
> error_directory /etc/squid/errors
> uri_whitespace allow
>
>
>
> --
> Chris Dent.Coppertop Patriarchies create children.
> .....Kiva Networking
>
>
Received on Fri Jul 16 1999 - 00:26:16 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:47:26 MST