Re: FW: [squid-users] Problems posting form data using IE6

From: Chris Robertson <[email protected]>
Date: Fri, 12 Oct 2007 15:40:53 -0800

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@nederweert.nl]
> Verzonden: donderdag 27 september 2007 13:09
> Aan: squid-users@squid-cache.org
> Onderwerp: [squid-users] 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
Received on Fri Oct 12 2007 - 17:41:01 MDT

This archive was generated by hypermail pre-2.1.9 : Thu Nov 01 2007 - 13:00:01 MDT