https://bugzilla.wikimedia.org/show_bug.cgi?id=38888
--- Comment #11 from Bawolff <[email protected]> 2012-08-02 13:21:51 UTC --- >First, this extension causes cache fragmentation, so we have one version of >each language in the parser cache. If I am not mistaken, it should be possible >for squid caching to still be active, it might even work with the current >setup. Note that the parser cache and squid cache are totally separate. I believe that MW disables squid caching for any request with the uselang parameter (However, when i looked for the code to accomplish this in MW, I could not find it, but i didn't look all that hard. on enwikipedia in my own testing, and request with uselang generates a cache miss). Furthermore if squid caching wasn't disabled for those urls, you would end up with a lot of stale results, since those urls are not purged. Hence I don't neccesarily think (imho) it's a bad thing that the squid cache is essentially for all intents and purposes disabled with this extension, but at the same time that's something that should be mentioned explicitly in the extensions docs if it is the case. >For logged in users on the other hand, it is very unlikely that one user speaks >all of those languages, we just know the user knows the language which is >chosen as its interface language I don't think that's a particularly good assumption. How many people even know Special:preferences exists. (OTOH it may be a good asumption if the language selected via this extension that the user creates an account with carries over to be the interface language, but SUL probably would make that not be realistic to happen). ---- >Running regexs on final html output is a little icky ;) Further on that note, what if MW (or an extension) outputted a form that had a literal '>' in one of its attributes. My understanding is that unescaped '>' characters are valid in an attribute (albeit I haven't been able to find anywhere in MW that does this [or at least does that and is manipulatable by the user] for form elements, although in theory I believe the HTML class would if it was used for form elements). This would at the very least alter the forms html into something invalid and unintended. And furthermore would quite possibly be an XSS issue [in particular if $wgWellFormedXml is off [See HTML::expandAttributes], smarter minds than me might be able to think of security issues even with that setting on] . -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
