Last modified: 2012-02-22 12:38:15 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 28840 - Loader broken in IE because mediawiki thinks the periods in module names is a security leak (spoof extension)
Loader broken in IE because mediawiki thinks the periods in module names is a...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
unspecified
All All
: High normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-reviewed
: 28847 28874 28877 28878 28890 28962 29010 29158 (view as bug list)
Depends on:
Blocks: 28891 26676 27699 28851 28962
  Show dependency treegraph
 
Reported: 2011-05-05 20:12 UTC by iain.macdonald
Modified: 2012-02-22 12:38 UTC (History)
25 users (show)

See Also:
Web browser: Internet Explorer
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
How a diff displays in IE. Firefox displays this properly with all the highlighting etc. (160.67 KB, image/jpeg)
2011-05-05 20:12 UTC, iain.macdonald
Details
Firefox displays it properly. (113.56 KB, image/jpeg)
2011-05-05 20:14 UTC, iain.macdonald
Details
Still not working (97.51 KB, image/jpeg)
2011-05-07 11:19 UTC, iain.macdonald
Details
patch to use ! marks instead of .'s in module names during requests (2.17 KB, patch)
2011-05-08 04:52 UTC, Bawolff (Brian Wolff)
Details

Description iain.macdonald 2011-05-05 20:12:50 UTC
Created attachment 8508 [details]
How a diff displays in IE. Firefox displays this properly with all the highlighting etc.

Running a Windows machine, I find diffs are not displaying properly in Internet Explorer.
Comment 1 iain.macdonald 2011-05-05 20:14:07 UTC
Created attachment 8509 [details]
Firefox displays it properly.
Comment 2 Roan Kattouw 2011-05-05 20:15:12 UTC
Does hard-refreshing the page (Ctrl+F5) fix it?
Comment 3 iain.macdonald 2011-05-05 20:19:51 UTC
Sometimes. Sometimes not - and, experiment shows, sometimes hard refreshing on the rare occasions it displays properly actually leads to the diff ceasing to display correctly.
Comment 4 Brion Vibber 2011-05-05 21:30:33 UTC
Likely related to bug 27488, bug 27769; might be some oddity disturbing the post-loading of the styles.
Comment 5 Michael M. 2011-05-06 07:37:05 UTC
Loading
http://bits.wikimedia.org/de.wikipedia.org/load.php?debug=false&lang=de&modules=mediawiki.legacy.diff&only=styles&skin=vector
directly in IE 8 gives me a 403 Forbidden, although the download of the CSS starts in background.

On secure.wikimedia.org not only diff.css but almost all CSS and JS seems to be missing.
Comment 6 Roan Kattouw 2011-05-06 09:28:01 UTC
We had an out-of-sync server in the bool, that's probably what was causing this. Is this fixed now?
Comment 7 iain.macdonald 2011-05-07 00:50:45 UTC
Sadly, no, it doesn't seem to be. I'll try again around noon UTC.
Comment 8 db [inactive,noenotif] 2011-05-07 08:49:14 UTC
It is working fine on local installation with r87481, update to r87482 breaks it.
Comment 9 iain.macdonald 2011-05-07 11:19:43 UTC
Created attachment 8517 [details]
Still not working

Going over into IE it is still much the same, despite again attempting hard refresh.
Comment 10 p858snake 2011-05-07 11:24:53 UTC
CCing Tim, since this is possibly caused by the security fix by the look of the other comments.
Comment 11 Ningauble 2011-05-07 11:57:46 UTC
See also bug 27814, bug 28851, and bug 28857 !
See also problem reports at http://meta.wikimedia.org/wiki/Wikimedia_Forum#Troubles
Comment 12 Bawolff (Brian Wolff) 2011-05-08 04:32:37 UTC
Updating bug summary based on duplicate bug's comments
Comment 13 Bawolff (Brian Wolff) 2011-05-08 04:52:01 UTC
Created attachment 8519 [details]
patch to use ! marks instead of .'s in module names during requests

So based on above comments this is triggered by the whole IE6 is stupid with extensions issue, combined with using dots to denote the hierarchy of RL module names.

So the most obvious fix (but rather hacky) would be to use ! marks instead of dots to denote the hierarchy (! mark chosen arbitrary. Perhaps something that isn't hex escaped would be better). This patch does that (only during requests for the user. Everything in the backend is still periods.) Not sure if this is an acceptable solution.

In my testing this patch does fix the issue on IE.
Comment 14 Derk-Jan Hartman 2011-05-08 15:18:32 UTC
*** Bug 28874 has been marked as a duplicate of this bug. ***
Comment 15 Derk-Jan Hartman 2011-05-08 15:20:13 UTC
*** Bug 28847 has been marked as a duplicate of this bug. ***
Comment 16 Roan Kattouw 2011-05-09 11:31:22 UTC
It seems to me like the IE 6 security measure is overinclusive. Tim, didn't you say the bug only affected URLs that don't have an extension before the question mark? load.php URLs always do, so they should be fine.
Comment 17 Daniel Tar 2011-05-09 11:56:21 UTC
*** Bug 28877 has been marked as a duplicate of this bug. ***
Comment 18 Roan Kattouw 2011-05-09 12:01:38 UTC
*** Bug 28890 has been marked as a duplicate of this bug. ***
Comment 19 Roan Kattouw 2011-05-09 13:31:05 UTC
(In reply to comment #13)
> Created attachment 8519 [details]
> patch to use ! marks instead of .'s in module names during requests
> 
> So based on above comments this is triggered by the whole IE6 is stupid with
> extensions issue, combined with using dots to denote the hierarchy of RL module
> names.
> 
> So the most obvious fix (but rather hacky) would be to use ! marks instead of
> dots to denote the hierarchy (! mark chosen arbitrary. Perhaps something that
> isn't hex escaped would be better).
Hmm. The exclamation marks get urlencoded in the URLs that MW outputs in the
HTML (e.g. for <link href="...">) but not for AJAX requests, at least in
Firefox.

> This patch does that (only during requests
> for the user. Everything in the backend is still periods.) Not sure if this is
> an acceptable solution.
> 
Thanks for this patch. It's not a good permanent solution IMO, but it's the
best we have right now to fix the site for IE users.

I committed the patch in r87711 and applied it to 1.17wmf1 (by hand) in r87712,
which is live now. The breakage should disappear within 10 minutes for
logged-in IE users, and may persist a bit longer for anonymous IE users.

Not closing the bug as FIXED because the fix is temporary and ugly.
Comment 20 Ningauble 2011-05-09 14:30:14 UTC
(Re. comment #11)
> See also bug 27814, bug 28851, and bug 28857 !

Typo: I meant bug 28714, not 27814.
Comment 21 Mark A. Hershberger 2011-05-09 15:42:32 UTC
*** Bug 28878 has been marked as a duplicate of this bug. ***
Comment 22 Bawolff (Brian Wolff) 2011-05-19 06:04:49 UTC
*** Bug 29010 has been marked as a duplicate of this bug. ***
Comment 23 Krinkle 2011-05-21 16:42:44 UTC
Making the summary sane and shorter.
Comment 24 Roan Kattouw 2011-05-26 09:50:04 UTC
Fixed in r88883.
Comment 25 Mark A. Hershberger 2011-05-26 18:54:42 UTC
*** Bug 28962 has been marked as a duplicate of this bug. ***
Comment 26 Roan Kattouw 2011-05-26 20:37:29 UTC
*** Bug 29158 has been marked as a duplicate of this bug. ***
Comment 27 Paul Oranje 2011-05-26 21:52:36 UTC
Will the patch be applied onto branches/REL1_17 (and when) so that the fix can be got with svn update?
Comment 28 Brion Vibber 2011-05-27 21:08:44 UTC
I still see this on trunk in r88997, and it's affecting Firefox 4 not just IE.

Reproduce:
1) Enable MwEmbedSupport extension in LocalSettings.php:
require( "$IP/extensions/MwEmbedSupport/MwEmbedSupport.php" );

2) Load up a page on the wiki

3) See a 403 Forbidden error for load.php of some initial modules, and JS errors due to jQuery and mw not being loaded by:

http://stormcloud.local/trunk/load.php?debug=true&lang=en&modules=jquery%7Cmediawiki%7Cjquery.triggerQueueCallback%7Cjquery.mwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20110526T174802Z

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>Forbidden</title></head><body><h1>Forbidden</h1><p>Invalid file extension found in PATH_INFO or QUERY_STRING.</p></body></html>
Comment 29 Brion Vibber 2011-05-27 21:29:38 UTC
I also see this for some things still using legacy action=raw to load site css pages, such as [[MediaWiki:Filepage.css]] being loaded by ImagePage:

http://stormcloud.local/trunk/index.php?title=MediaWiki:Filepage.css&action=raw&maxage=18000&usemsgcache=yes&ctype=text%2Fcss&smaxage=18000

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"><html><head><title>Forbidden</title></head><body><h1>Forbidden</h1><p>Invalid file extension found in PATH_INFO or QUERY_STRING. Raw pages must be accessed through the primary script entry point.</p></body></html>

Manually adding a '&*' on the end of the URL resolves it (as does removing the '.' from the '.css' though obviously then it doesn't load!)
Comment 31 Brion Vibber 2011-05-27 23:47:33 UTC
(Fixing deps/blockers; RL, API, and action=raw failures here all affect TimedMediaHandler: bug 27699).
Comment 32 Derk-Jan Hartman 2011-05-29 11:10:28 UTC
So it this going anywhere ? Cause it is heavily breaking other platforms atm, i'm starting to nudge towards 'revert and IE6 is no longer supported + banner "upgrade your browser"'.
Comment 33 Tim Starling 2011-05-31 00:37:44 UTC
It should be fixed as of r88883, to be released soon.
Comment 34 Derk-Jan Hartman 2011-05-31 12:35:20 UTC
Well brion and I myself experienced issues after r88883 it seems. At least I had my trunk up to date, and I doubt that brion wasn't using up to date trunk.
Comment 35 Derk-Jan Hartman 2011-05-31 12:36:09 UTC
(In reply to comment #34)
> Well brion and I myself experienced issues after r88883 it seems. At least I
> had my trunk up to date, and I doubt that brion wasn't using up to date trunk.

He actually specifically says: "I still see this on trunk in r88997"
Comment 36 Tim Starling 2011-05-31 23:56:34 UTC
We can fix a few more special cases, but there's not going to be a solution for this that can allow any arbitrary api.php or action=raw request.
Comment 37 Tim Starling 2011-06-01 02:56:16 UTC
It should be somewhat better as of r89249. It should mostly only block requests that have dots in the last parameter of the query string now. 

One possible way to make it break less things would be to have it redirect to a safe equivalent of the same URL, instead of showing an error page. It wouldn't help with POST requests that have some parameters in the URL, and it wouldn't help with API clients that don't understand redirects, but at least it would fix any JavaScript client issues. What do you think?
Comment 38 Michael Dale 2011-06-01 02:59:33 UTC
bug 29224 is related patch for the RL start-up module names not using Packed Module String
Comment 39 Tim Starling 2011-06-03 05:49:19 UTC
(In reply to comment #37)
> One possible way to make it break less things would be to have it redirect to a
> safe equivalent of the same URL, instead of showing an error page.

Done in r89397.
Comment 40 Krinkle 2011-06-06 16:54:41 UTC
(In reply to comment #39)
> (In reply to comment #37)
> > One possible way to make it break less things would be to have it redirect to a
> > safe equivalent of the same URL, instead of showing an error page.
> 
> Done in r89397.

Can this ticket be closed now or is there still something pending ?
Comment 41 Paul Oranje 2011-06-06 17:16:25 UTC
Shouldn't r89397 be tagged with 1.17, 1.17wmf1?
OT: When do (ports of) these revisions land on the 1.17 branch?
Comment 42 Roan Kattouw 2011-06-06 17:42:50 UTC
(In reply to comment #41)
> Shouldn't r89397 be tagged with 1.17, 1.17wmf1?
It will be once I review it.

> OT: When do (ports of) these revisions land on the 1.17 branch?
Probably this week.
Comment 43 Mark A. Hershberger 2011-06-07 02:11:41 UTC
(In reply to comment #40)
> Can this ticket be closed now or is there still something pending ?

Roan can close it once he has reviewed the patch.  This is the last real blocker to 1.17.  No pressure, though. ;)
Comment 44 Roan Kattouw 2011-06-07 20:32:55 UTC
(In reply to comment #41)
> Shouldn't r89397 be tagged with 1.17, 1.17wmf1?
> OT: When do (ports of) these revisions land on the 1.17 branch?
Tim's already merged them, apparently.

(In reply to comment #43)
> (In reply to comment #40)
> > Can this ticket be closed now or is there still something pending ?
> 
> Roan can close it once he has reviewed the patch.  This is the last real
> blocker to 1.17.  No pressure, though. ;)
Tim's code is fine, closing this bug.
Comment 45 Mark A. Hershberger 2011-06-22 18:46:45 UTC
*** Bug 29531 has been marked as a duplicate of this bug. ***
Comment 46 p858snake 2011-06-22 22:43:54 UTC
Mark: Please explain why you reopened this bug.
Comment 47 Tim Starling 2011-06-22 23:17:10 UTC
It's probably easier to keep bug 29531 separate, since it doesn't seem to be very closely related to this bug.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links