ucla/mwf — Issue #40: IE Quirks Mode / Standards Mode Mismatch b/t target page and passthru.php results in infinite redirect loop
Author: Trott
Created: 2011-12-12 22:35:47+00:00
State: open

Yup, that's it. passthru.php outputs an HTML document with no doc type, throwing IE into quirks mode.

If you're target doc also puts IE into quirks mode, you're good.

If you use then it's standards mode and you enter redirect loop nightmare.

If you put that doctype into passthru.php, you get the opposite behavior: Quirks mode pages go into infinite redirect loops and standards mode pages work.

Eric, I don't know enough about why there's that extra classification check in the DTS that's giving us heartburn here--I'm sure there's a good reason for it, but I don't know what that reason is--do I'm kicking this over to you at this point. (Yay, no more emails from me today!)

I'll open an issue in GitHub.

--Rich

________________________________________
From: Trott, Richard
Sent: Monday, December 12, 2011 2:17 PM
To: Bollens, Eric; Vega; Jim Kreuziger
Cc: Christopher Davis; Sakabu, Edward
Subject: RE: UCI Libraries mobile url for MWF test site

As Mark/Vega/help-me-out-what-do-I-call-you pointed out, it's flapping between standards mode on the content page and quirks mode in passthru.php. So that's probably what's causing the classification to change and thus the infinite redirect loop.

Why do we do the check for change in classification? Without knowing that, I can't be sure that anything I suggest is going to be a good suggestion, but that won't stop me:

It may be tempting to try to do something to force it into one mode or another, but I suspect we should just accept that we can't actually force the browser to reveal the same things all the time. I think we should just believe what it's telling us on the page that we're on, overwrite the cookie there, and reload. (Yeah, it's an extra HTTP request. Oh well. Another argument for appcaching.) The only way that could cause an infinite redirect loop is if the browser reports different things on every request to the same page.

--Rich

________________________________________
From: Trott, Richard
Sent: Monday, December 12, 2011 2:07 PM
To: Bollens, Eric; Vega; Jim Kreuziger
Cc: Christopher Davis; Sakabu, Edward
Subject: RE: UCI Libraries mobile url for MWF test site

I wonder if this has to do with the browser toggling between standards mode and quirks mode perhaps due to the HTML5 doctype.
________________________________________
From: Trott, Richard
Sent: Monday, December 12, 2011 2:05 PM
To: Bollens, Eric; Vega; Jim Kreuziger
Cc: Christopher Davis; Sakabu, Edward
Subject: RE: UCI Libraries mobile url for MWF test site

Yes, and that's precisely the issue. I was mistaken when I said it wasn't being set. The value is indeed changing.

standard is false in site.cookie.classification but true in classificationCookie when you hit this line in server.src.js:

if(!site.cookie.exists(classification.cookieName) || site.cookie.classification != classificationCookie)

If you want to take this to IRC, we can probably get some stuff done faster. (And if you just want to take over at this point and fix it, even better. :-) )
________________________________________
From: Bollens, Eric
Sent: Monday, December 12, 2011 2:01 PM
To: Trott, Richard; Vega; Jim Kreuziger
Cc: Christopher Davis; Sakabu, Edward
Subject: Re: UCI Libraries mobile url for MWF test site

Hmmm, that's interesting... Let me know what you find with classification.
That's the only one that does more than a cookie existence check - it also
checks to make sure that the classification has not changed in the cookie.

~ Eric

On 12/12/11 1:56 PM, "Trott, Richard" wrote:

>I don't think it's #2. I'm stepping through in a debugger and that
>should give it plenty of time for the browser to take the cookie. I'm
>not ruling it out, but I don't think so if I have to guess.
>
>I do notice that it seems to always be the classification cookie that
>fails, and not the other two.
>________________________________________
>From: Bollens, Eric
>Sent: Monday, December 12, 2011 1:51 PM
>To: Trott, Richard; Vega; Jim Kreuziger
>Cc: Christopher Davis; Sakabu, Edward
>Subject: Re: UCI Libraries mobile url for MWF test site
>
>Rich,
>
>The starting point here is mwf.server.mustReload. It is false by default,
>but set true whenever mwf.server.setCookie() is called. This implies that
>one or more of the mwf.site.cookie.exists() calls in mwf.server.init() is
>failing (or that the classification has changed) again and again.
>
>I thus arrive at mwf.site.cookie.exists() as the likely culprit. This is
>written out in vars.php based on logic whereby the page checks for the
>user_agent, screen and override cookies, and writes them out if they
>exist. The exists() function then checks to see if the one provided in a
>parameter has been defined on the server.
>
>If mwf.site.cookie.exists() is returning false, that means that the cookie
>hasn't stuck to the server yet. This would mean that passthru.php is
>proving ineffective in setting the cookie.
>
>Two reasons that passthru.php might fail:
>
>(1) The browser does not accept cookies but the mwf.capability.cookie()
>check believes it does.
>
>(2) Javascript on the page is redirecting the user before the browser
>processes the cookie write.
>
>I doubt that the issue is (1) given that IE 9 is almost certainly
>accepting cookies. However, (2) might be more likely. Imagine, for
>instance, if IE 9 doesn't process cookies until a certain elapsed time,
>say at onLoad, as opposed to immediately when document.cookie is called. I
>think the test, therefore, would be to modify passthru.php to not redirect
>until onLoad or onDOMContentLoaded. This will induce a slight delay in the
>redirect, but might solve the problem.
>
>Thoughts?
>
>~ Eric
>
>On 12/12/11 1:39 PM, "Trott, Richard" wrote:
>
>>D'oh! Port 80 blocked at the campus perimeter.
>>
>>I can put it on another port, but really, all you have to do is copy and
>>paste the source from the UCI lib page, uncomment the script and change
>>the redir target to your script location.
>>
>>Looks to me like this bit of code is always firing on every page visit:
>>
>> else{
>> if(this.mustRedirect&&!mwf.override.isRedirecting){
>>
>>window.location=b.asset.root+"/passthru.php?return="+encodeURIComponent(w
>>i
>>ndow.location)
>> }
>>
>>Obviously, it should fire (at most) just the first time.....
>>
>>--Rich
>>
>>________________________________________
>>From: Bollens, Eric
>>Sent: Monday, December 12, 2011 1:37 PM
>>To: Trott, Richard; Vega; Jim Kreuziger
>>Cc: Christopher Davis
>>Subject: Re: UCI Libraries mobile url for MWF test site
>>
>>Can't seem to access that address Rich...
>>
>>Any idea what's causing it?
>>
>>~ Eric
>>
>>On 12/12/11 1:36 PM, "Trott, Richard" wrote:
>>
>>>Although no rush, since I now have the bug running on my own local
>>>machine.
>>>
>>>Eric, if you need an installation that shows the bug, point your IE
>>>browser at http://128.218.15.246/test.php
>>>
>>>--Rich
>>>
>>>________________________________________
>>>From: Bollens, Eric
>>>Sent: Monday, December 12, 2011 1:33 PM
>>>To: Trott, Richard; Vega; Jim Kreuziger
>>>Cc: Christopher Davis
>>>Subject: Re: UCI Libraries mobile url for MWF test site
>>>
>>>Rich is correct. Without that line, the MWF cannot determine what your
>>>device is capable of. All phones will instead get the basic-grade CSS
>>>and
>>>no JS support.
>>>
>>>~ Eric
>>>
>>>On 12/12/11 1:30 PM, "Trott, Richard" wrote:
>>>
>>>>You really need to put that line back. Removing it is not the
>>>>solution.
>>>>There's a bug in there that needs fixing, but you need the JS code that
>>>>script tag provides.
>>>>________________________________________
>>>>From: Vega
>>>>Sent: Monday, December 12, 2011 12:46 PM
>>>>To: Kreuziger, Jim
>>>>Cc: Trott, Richard; Bollens, Eric; Christopher Davis
>>>>Subject: Re: UCI Libraries mobile url for MWF test site
>>>>
>>>>The endless redirect seems to stop when I remove the following from the
>>>>head section:
>>>>
>>>>
>>>>
>>>>Once removed, the page loads but with incorrect styling. In
>>>>particular,
>>>>IE seems to be ignoring 'text-align: center;', 'display:
>>>>inline-block;',
>>>>and all three types of gradients (moz-, webkit-, and o-).
>>>>
>>>>
>>>>Jim: I did test on your wife's Windows phone on Friday as well which
>>>>is
>>>>what alerted me to the problem. The page loaded (no redirect loop),
>>>>but
>>>>did not display with correct styling.
>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>Vega
>>>>
>>>>
>>>>
>>>>On 12/12/2011 12:33 PM, Kreuziger, Jim wrote:
>>>>> Nothing has changed on the site. I've looked at the site on Windows
>>>>> mobile (my wife's phone) and it looked pretty messed up (that's the
>>>>> technical term ;)). Since I only have access to the phone when I'm
>>>>>not
>>>>>at
>>>>> work, I'm going to fire up my windows VM to see if I can reproduce
>>>>>any
>>>>>of
>>>>> this.
>>>>>
>>>>> I'll remove the trailing slash on site_url... Ok, that's done. Let
>>>>>me
>>>>> know if that makes a difference.
>>>>>
>>>>> Jim Kreuziger
>>>>> Director, Web Communications
>>>>> University Communications
>>>>> University of California, Irvine
>>>>> www.uci.edu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 12/12/11 11:03 AM, "Trott, Richard"
>>>>>wrote:
>>>>>
>>>>>> Jim, I was able to reproduce this problem on Friday using Internet
>>>>>> Explorer, but today I am unable to do so. Any idea if anything
>>>>>>changed?
>>>>>> I'm hoping the answer is "yes" but I'm guessing the answer is "no".
>>>>>>
>>>>>> Anyway:
>>>>>>
>>>>>> site_url has a trailing slash. The trailing slash should be
>>>>>>removed,
>>>>>> although I don't know that it would be causing the behavior we're
>>>>>>seeing.
>>>>>> (Seems unlikely, but Eric would know a lot more.)
>>>>>>
>>>>>> --Rich
>>>>>>
>>>>>> ________________________________
>>>>>> From: Kreuziger, Jim
>>>>>> Sent: Monday, December 12, 2011 10:51 AM
>>>>>> To: Trott, Richard; Bollens, Eric
>>>>>> Cc: Vega
>>>>>> Subject: Re: UCI Libraries mobile url for MWF test site
>>>>>>
>>>>>> Rich, Eric,
>>>>>>
>>>>>> I'm currently running 1.2.07. I have 1.2.08 in the queue, should be
>>>>>>able
>>>>>> to update sometime today. I'm going to attach a copy of my
>>>>>>global.php
>>>>>> config file, in case this is something you can use.
>>>>>>
>>>>>> Right now, Vega is the only one outside the actual framework that
>>>>>>has
>>>>>> tried to create a site. Our UCI mobile site is being developed on
>>>>>>the
>>>>>> domain (m.uci.edu) that the framework resides.
>>>>>>
>>>>>> Let me know if there is anything that I can do to help.
>>>>>>
>>>>>> Jim Kreuziger
>>>>>> Director, Web Communications
>>>>>> University Communications
>>>>>> University of California, Irvine
>>>>>> www.uci.edu
>>>>>>
>>>>>> From: Vega
>>>>>> Date: Mon, 12 Dec 2011 07:02:36 -0800
>>>>>> To: Jim Kreuziger
>>>>>> Subject: Fwd: RE: UCI Libraries mobile url for MWF test site
>>>>>>
>>>>>> Jim,
>>>>>> I'm having some problems with my new MWF-based mobile site
>>>>>> (http://www.lib.uci.edu/mwf-test/) in Internet Explorer (desktop and
>>>>>> Windows phone) and reported such at Friday's MWF Developers meeting.
>>>>>> Eric Bollens and Rich Trott asked me to send them the url and you
>>>>>>can
>>>>>>see
>>>>>> Rich's troubleshooting notes in the email below. I'm not sure,
>>>>>>though,
>>>>>> why the trouble only presents in IE...
>>>>>>
>>>>>> --
>>>>>> Vega
>>>>>> --
>>>>>>
>>>>>> -------- Original Message --------
>>>>>> Subject: RE: UCI Libraries mobile url for MWF test site
>>>>>> Date: Fri, 9 Dec 2011 23:56:04 +0000
>>>>>> From: Trott, Richard
>>>>>> To: Vega, Eric Bollens
>>>>>>
>>>>>>
>>>>>>
>>>>>> More notes for Eric:
>>>>>>
>>>>>> * You can see the problem in IE, so you don't need to get a Windows
>>>>>>phone
>>>>>> or anything.
>>>>>>
>>>>>> * Their MWF code appears to have all the important relevant bugfixes
>>>>>>that
>>>>>> have been committed to master (unless their doing something weird
>>>>>>like
>>>>>> protocol-less URLs, but who does that besides idiots like me?). You
>>>>>>can
>>>>>> see, for example, their JS source at
>>>>>> http://m.uci.edu/mwf/current/root/assets/js/
>>>>>>
>>>>>> * Might want to mail Jim K. or whoever and get their config settings
>>>>>>to
>>>>>> see if you can replicate this.
>>>>>>
>>>>>> * IE is working fine on m.uci.edu, so it's probably something to do
>>>>>>with
>>>>>> this being a client on its own server and not an SP.
>>>>>>
>>>>>> * Ready to switch to OpenDDR? :-P
>>>>>>
>>>>>> --Rich
>>>>>>
>>>>>> ________________________________________
>>>>>> From: Trott, Richard
>>>>>> Sent: Friday, December 09, 2011 3:40 PM
>>>>>> To: Vega; Eric Bollens
>>>>>> Subject: RE: UCI Libraries mobile url for MWF test site
>>>>>>
>>>>>> Eric, this looks like DTS loop trouble. I hope they're running an
>>>>>>MWF
>>>>>> that is a couple versions back and that they just need to update.
>>>>>> ________________________________________
>>>>>> From: Vega [
>>>>>> Sent: Friday, December 09, 2011 3:27 PM
>>>>>> To: Eric Bollens; Trott,
>>>>>>Richard
>>>>>> Subject: UCI Libraries mobile url for MWF test site
>>>>>>
>>>>>> Rich, Eric;
>>>>>> Here is url to my test instance of mobile site using MWF:
>>>>>>
>>>>>> http://www.lib.uci.edu/mwf-test/
>>>>>>
>>>>>> Looks great on iPhone, Android but breaks on Windows phone and in
>>>>>> desktop version of IE9.
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> Mark Vega
>>>>>> Programmer/Analyst
>>>>>> UCI Libraries - Web Services
>>>>>> The University of California, Irvine
>>>>>> P.O. Box 19557
>>>>>> Irvine, CA 92623-9557
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>