On 10/19/10 1:29 PM, Roan Kattouw wrote: Isn't it fairly common to load data or other such page fragments in this way, though? Or does it only seem common to me because I commonly work with Commons? -- Neil Kandalgaonkar |) <neilk(a)wikimedia.org>

On Tue, Oct 19, 2010 at 1:57 PM, Neil Kandalgaonkar <neilk(a)wikimedia.org> wrote: I'm not so much suggesting it as I am stating the status quo, and asking whether we should document it well or change the code. And they did. See https://bugzilla.wikimedia.org/show_bug.cgi?id=25564 On 10/19/10 1:29 PM, Roan Kattouw wrote: I guess I'm not quite so confident this problem won't rear it's head again, but since it's a theoretical problem at this point, and we have enough actual problems to deal with, I'm happy to drop it for now. Rob

Hi! Pretty URLs are for being pretty URLs (e.g. in your address bar). That leads to very easy assumption, that if there's a pretty URL, it probably indicates a pageview :-) We quite like other pretty URLs for Special pages e.g. Watchlist or Recentchanges - as we track their accesses. Heh, apparently stats became a big deal lately, so one with powers to change that can feel important! ;-) Anyway, there're few choices to resolve it on the stats side: 1) Implement pulling of a namespace map for each project, build out an efficient rules engine (in C) for dealing with this (do note, every project will have different namespace for this URL). Also, make it extensible, so each developer tells about which names will be not-a-pageview ;-) There's nothing as fun as writing that kind of code, and do note, it won't be just five (or fifty) lines. 2) Add additional internal header (X-Pageview: true!), that would be logged by squids inside the stream :) That probably asks for large review inside MediaWiki, as well as squid code changes (and of course, rollout of new binary). Would be nice inter-group effort. 3) Not care about inflated per-project numbers, or have people adjust the numbers, as the source data is there (They can filter out banner loader themselves!) You can pick any of these, make sure it gets into strategy plan, as we don't decide things on wikitech-l anymore :) I prefer, hehehe, not doing anything, and just having pretty URLs just for pageviews ;-) Domas

Op 20 okt 2010, om 00:09 heeft Marco Schuster het volgende geschreven: But the short version without /w/index.php but with direct ?parameters doensn't for for action=raw (&ctype=text/javascript) See the errror on: http://meta.wikimedia.org/wiki/User:Krinkle/global.js?action=raw Nor does (atleast did) the software never point to a non-viewing page in the short form. -- Krinkle

On Tue, Oct 19, 2010 at 4:15 PM, Marco Schuster < marco(a)harddisk.is-a-geek.org&gt; wrote: Internet Explorer, at least until recently (might finally be fixed?), would sometimes interpret "file extensions" on the end of a URL's path component as if they were meaningful file type information, especially when combined with actual content-type headers it considered "ambiguous". A pretty URL such as " http://meta.wikimedia.org/wiki/Something.html?action=raw" would thus be dangerous, as the ".html" on the end of the wiki page -- a completely meaningless piece of an opaque URL path -- could trigger interpretation of the file's content as actual HTML, etc, thus become a vector for JavaScript injection into the wiki's same-origin security context. To keep that nailed down, we forbade access to action=raw unless the URL's path portion matched the wiki's core entry point exactly. There may be nicer ways to do this now. :) Back to the original issue -- I agree with Roan that the best way to go is to make sure most such things as the BannerLoader get converted to use the ResourceLoader interface, which eliminates the need to create and manage as many JS/CSS special-page points like this. I think BannerLoader is part of CentralNotice, which is Scary Code and may or may not fit in nicely though. *shudder* If making short-term tweaks to it without redoing it, be very careful about caching! -- brion