Thanks Amos, What's happening is quite similar to the details described in the aforementioned Firefox bug filing.
When the "attach file" function is started in the Yahoo Mail compose message window and a file is selected from the user's desktop filesystem, a new HTTP POST operation is initiated to squid. This is a new tcp session entirely. The POST operation is a form served by host sp1.attach.mail.yahoo.com using a Shockwave Flash user-agent - so I'm assuming the browser itself sits this one out. Here's the first little bit of the request, it's followed by form-data such as "filename" and "content-type" etc. >>>>>> POST http://sp1.attach.mail.yahoo.com/ca.f431.mail.yahoo.com/ya/upload_with_cred?-- HTTP/1.1 Accept: text/* Content-Type: multipart/form-data; boundary=----------cH2ae0gL6KM7ei4ei4ei4Ij5Ij5KM7 User-Agent: Shockwave Flash Host: sp1.attach.mail.yahoo.com Content-Length: 719794 Proxy-Connection: Keep-Alive Pragma: no-cache Cookie: B=dgrausd7a344r&b=4&d=vku6LippYFR6PRpZokl3s5qyCUJklnhtfiFf&s=pt&i=A6MbHqjIfHzX9QIh5CDC; >>>>>>> Squid responds to this initial POST operation with the predictable TCP_DENIED/407 "Cache Access Denied" message: from access.log: Sun Feb 5 22:29:16 2012 3 172.16.130.22 TCP_DENIED/407 5626 POST http://sp1.attach.mail.yahoo.com/ca.f431.mail.yahoo.com/ya/upload_with_cred? - NONE/- text/html >>>>>>> HTTP/1.0 407 Proxy Authentication Required Server: squid/3.1.11 Mime-Version: 1.0 Date: Mon, 06 Feb 2012 03:29:16 GMT Content-Type: text/html Content-Length: 5206 X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0 Vary: Accept-Language Content-Language: en Proxy-Authenticate: Negotiate X-Cache: MISS from localhost X-Cache-Lookup: NONE from localhost:3128 Via: 1.0 localhost (squid/3.1.11) Connection: keep-alive >>>>>>>> Squid actually serves up the full "407 Denied" webpage, but it's not presented to the user. Instead, the Yahoo Flash user-agent seems to trample on instead and attempts to send the attachment anyway, without first re-sending the request with the credentials required to access squid. I can see the pdf being uploaded to the squid server, but squid just ignores it. This manifests as a "hanging" upload window to the user. I guess I need to know where to look in order to find out why the request is not re-sent using the proper credentials. Is it the Yahoo user-agent? is it the browser? Thanks, Hank > Date: Sat, 4 Feb 2012 18:39:23 +1300 > From: [email protected] > To: [email protected] > Subject: Re: [squid-users] POST method when using squid_kerb_auth and sending > Yahoo mail attachment > > On 4/02/2012 12:46 p.m., Hank Disuko wrote: > > Hello folks, > > > > I'm using squid 3.1.11-1 on Ubuntu Server 11. I am > > using "/usr/lib/squid3/squid_kerb_auth" to auth against a Windows 2008 > > directory. > > > > I am unable to upload attachments to emails when using the *new* Yahoo! > > Mail interface. The old interface seems to work fine. > > > > I've seen this problem reported around the internet. These older posts > > reveals some insight: > > > > http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-NTML-and-auth-problems-with-POST-td2255704.html > > This is a well known problem with NTLM design. Kerberos was re-designed > to avoid this. Since you are apparently Negotiate protocol with a > Negotiate/kerberos helpers it is not relevant. > > > > > http://www.squid-cache.org/mail-archive/squid-users/200506/0158.html > > ditto here. > > > I made a "POST_whitelist.txt" for .yahoo.com and uploads work fine. But > > this is an ugly workaround. > > > > More recently, someone also experiencing this issue filed a Firefox bug. > > But I'm quite sure it's not a Firefox issue: > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=679519 > > > > Any better fix for this out there? > > The bug reported to firefox seems to be about Basic authentication. > Which is also irelevant. > > To provide any more help than that we will need to know exactly what is > going on in your system. What is being requested from Squid, what Squid > is responding with, anything Squid logs about the transaction, and how > it is configured. > > Amos
