J Beris wrote:
Hello all,
I did not receive any reply to the question below. This is not a
complaint, but I am merely trying to understand why that is or if I did
something that is not considered correct etiquette on this list which
made people ignore my message. Of course it also possible that:
A) I worded my question in an unintelligible way
B) Nobody has an answer for me
I'd go with choice B. The problem is just baffling and no one has run
across it before. But see below for some W.A.G.
Please let me know!
Thank you,
Joop
-----Oorspronkelijk bericht-----
Van: J Beris [mailto:J.Beris@xxxxxxxxxxxxx]
Verzonden: donderdag 27 september 2007 13:09
Aan: squid-users@xxxxxxxxxxxxxxx
Onderwerp: Problems posting form data using IE6
Hello everyone,
Some users at our site are having difficulty using websites with forms
which they need to fill in when they use IE6. Connecting to the same
sites with Firefox works as expected. We are using Squid 2.6.STABLE6-0.6
on an openSUSE 10.2 machine (rpm package, not built from source).
The problem with IE is that users experience time-outs when trying to
post data entered in forms. The information is saved at the site though,
as completing the same form with the same data again, results in an
error that there already exists such a record.
The strange thing is that the user gets the default IE error page for a
time-out, not the Squid error page for a time-out.
In access.log, the following is logged:
1190878061.492 31383 10.254.202.86 TCP_MISS/302 487 POST
http://www.ckb-online.nl/Dossierbeheer/AanmakenDossier.aspx jbs
DIRECT/213.206.93.222 text/html
So the result of the POST is a redirect. Fair enough...
1190878061.543 0 10.254.202.86 TCP_DENIED/407 2020 GET
http://www.ckb-online.nl/ErrPage.aspx - NONE/- text/html
This raises two questions for me:
1) Why did the authentication fail? It's being renegotiated.
2) Why is the client requesting the error page? I would assume that's
where the 302 points to, but that's an odd place to redirect a
successful POST to.
1190878061.546 0 10.254.202.86 TCP_DENIED/407 2197 GET
http://www.ckb-online.nl/ErrPage.aspx - NONE/- text/html
1190878071.347 9802 10.254.202.86 TCP_MISS/302 487 GET
http://www.ckb-online.nl/ErrPage.aspx jbs DIRECT/213.206.93.222
text/html
So the error page is a redirect too?
1190878071.350 0 10.254.202.86 TCP_DENIED/407 2020 GET
http://www.ckb-online.nl/ErrPage.aspx - NONE/- text/html
A redirect to itself??? And it causes the proxy credentials to fail as
well.
1190878071.353 0 10.254.202.86 TCP_DENIED/407 2197 GET
http://www.ckb-online.nl/ErrPage.aspx - NONE/- text/html
1190878075.893 4540 10.254.202.86 TCP_MISS/302 487 GET
http://www.ckb-online.nl/ErrPage.aspx jbs DIRECT/213.206.93.222
text/html
Round and round we go. No wonder IE eventually times out. Cut the rest
at an attempt at brevity...
The odd thing is that the user never gets to see the error page from
the server (see the line above). It just sits there and eventually times
out or just waits forever.
Due to the fact that the error page redirects continuously.
The TCP_DENIED/407 seems to have to do with
authentication, which is a bit odd, since the proxy is configured to not
allow cache access without authentication. We use Samba/Winbind to
authenticate users to Active Directory.
Hmmm... I was under the impression that NTLM auth showed up in the logs
with both the domain and the username. Then again, I don't use it...
With Firefox, I find the following lines in access.log:
1190879182.880 186 10.254.202.86 TCP_MISS/200 21291 GET
http://www.ckb-online.nl/WebResource.axd?d=vZzctey8hqFdK6AGNq0DGA2&t=633
201894100625000 jbs DIRECT/213.206.93.222 application/x-javascript
1190879183.145 265 10.254.202.86 TCP_MISS/200 21834 GET
http://www.ckb-online.nl/WebResource.axd?d=Wz_7lZQTVD_jDQGtPmKFCZE3OVMIf
bIM0FibHEhB2e41&t=633201894100625000 jbs DIRECT/213.206.93.222
application/x-javascript
1190879185.829 579 10.254.202.86 TCP_MISS/302 598 POST
http://www.ckb-online.nl/Dossierbeheer/Dossier.aspx?DossierID=3361 jbs
DIRECT/213.206.93.222 text/html
Where did the query term come from? That question mark and DossierID
weren't there for the IE request. Is Firefox blocking cookies? Also,
is Firefox authenticating via NTLM?
1190879186.099 271 10.254.202.86 TCP_MISS/200 23829 GET
http://www.ckb-online.nl/Dossierbeheer/BeheerChecklist.aspx?Dossier=3361
jbs DIRECT/213.206.93.222 text/html
That's a much more reasonable place to redirect a POST response to. And
the authentication is kept intact.
SNIP... It works. But it has query terms (DossierID and others). Why
the difference?
These seem like normal transaction lines to me.
When I allow the user to bypass the proxy and go directly to the site
with IE6, the site works as intended.
It would be interesting to see a traffic log of that (wireshark is your
friend). BTW, are you explicitly setting a proxy in the browser (or
using WPAD), or is this an intercepting proxy?
I have added the following acl statement to squid.conf to try and solve
this matter, but it doesn't seem to solve the problem:
acl CKBONLINE dstdomain .ckb-online.nl
always_direct allow CKBONLINE
Probably not going to do what you expect. always_direct and
never_direct deal with cache_peers. Once Squid has been handed the
traffic, it has to deal with it. There's no bridging mode.
So my question is, is there a setting I need to tweak for IE6 to start
working with these sites? Since it works with Firefox, my guess is that
IE6 does something that Squid does not like. Any ideas?
Here's my checklist of questions:
Is your set up an explicit proxy, or an intercepting (a.k.a.
transparent) proxy?
Why the difference in requests between IE and FF (one uses query terms,
the other doesn't)? Is it due to cookies being blocked? Is it due to a
difference in authentication method (either against the proxy, or the
web site itself)?
Why does the proxy authentication fail on POST for IE?
Why does the error page (http://www.ckb-online.nl/ErrPage.aspx) redirect
to itself?
Why does the proxy authentication fail on the error page?
Kind regards,
Joop Beris
Chris
