[squid-users] httpReadReply: Request not yet fully sent / POST problems?

Greetings!

I have a Debian Stable machine running the stock version of Squid
(2.5.STABLE9). It's set up as a transparent cache, with all traffic
over TCP port 80 redirected to the proxy. Additionally, we run adzap
as a redirector.

I have users that are complaining of failed uploads, mostly to picture
sites (ofoto, shutterfly, snapfish), but also to other sites
(facebook.com, myspace, etc). Checking the cache logs, the only
suspicious activity are lines that look like this:

(example of a Costco-branded snapfish upload)

2005/12/02 14:09:43| httpReadReply: Request not yet fully sent "POST
http://64.147.178.206/uploadimagebasic.suup?authcode=<snip>&
HOST_NAME=http://www.costcophotocenter.com"

I searched the FAQ and the list for that error message, and all I
could find was this:

    http://marc.theaimsgroup.com/?l=squid-users&m=111887530904985&w=2

The message suggests that the message can be safely ignored, but it
seems that there is a correlation between the messages and my failed
uploads. My question is: is this indicitive of the error I'm seeing,
or should I be looking elsewhere for the solution to my POST problems?

Stuff I've tried so far:

- Verified that POSTs work when I drop the proxy out of the equation
  (turn off the transparent redirect through the squid box).

- Turned off all redirectors (through adzapper) under Squid so it's
  just a straight caching proxy; problem still persists.

- Turned on explicit DIRECT for all POST method connections (pretty
  sure this doesn't change anything, but I'm just trying stuff out
  before I waste your time); problem still persists.

- Double-checked my "request_body_max_size" and other limit params to
  make sure I'm not killing the connections on my end; everything is
  set to "unlimited" (I can post my whole config if people would
  like).

- Sniffed some traffic on the wire, but didn't see anything
  immediately wrong. It looks like an initial burst of traffic during
  the POST, which quickly slows to a trickle. Eventually, the
  connection dies (or the user gives up), and the upload is aborted.
  I'm not sure why things would taper this way; I'm not using delay
  pools, and my upstream bandwidth isn't a problem.

Any suggestions would be most welcome.

Thanks,

Jason

-- 
Jason Healy
http://www.logn.net/