Requests with data URIs appended to proper URLs

List overview All Threads
Download

newer

older

Authorship metadata displayed at...

Changes in API...

Christian Aistleitner

5 Jun 2014 5 Jun '14

1:36 p.m.

Hi, requests matching http://$es\|pt$.wikipedia.org/wiki/[dD]ata:image/png;base64,iVBORw0K.* are on the increase. Currently, ~500K/day. I cannot make sense of those requests, and they look wrong, as they seem to be a data URI appended to the a proper URL [1]. Corresponding bug is 66112 [2]. The requests' User-Agent identifies them as Firefox and Chrome, both on various flavors of Windows. It's not ancient browsers, as the biggest part identifies as Firefox 29 (~60%) and Chrome 35 (~31%). It does not seem to be simple bots faking User-Agents, as the number of requests shows a strong weekly pattern and the Client IPs match countries for the target wikis, and the IPs themselves differ a lot—covering 200-500 /24 nets per day in sampled-1000 stream. Requests go to desktop site of eswiki (~58%) and ptwiki (~38%). Referrers are mostly empty (~97%). The image data in the data uri scheme decodes to images from VectorBeta [3] like: VectorBeta/resources/typography/images/search-fade.png VectorBeta/resources/typography/images/tab-break.png VectorBeta/resources/typography/images/tab-current-fade.png VectorBeta/resources/typography/images/portal-break.png Any clues? Is this issue on our end or can for example rogue User-JS amount for that many skew requests? Have fun, Chrisitan P.S.: On stat1002, there are TSVs from the sampled-1000 stream filtered to the relevant requests for May and June at /home/qchris/data-uris . [1] Since they are just UI images, here are some concrete examples: http://es.wikipedia.org/wiki/data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA… http://pt.wikipedia.org/wiki/Data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA… http://es.wikipedia.org/wiki/data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA… http://es.wikipedia.org/wiki/Data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA… [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=66112 [3] But that's not to say that it's a VectorBeta issue. It might be for example our (or User-)JS walking DOM and firing off strange requests. -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Gruendbergstrasze 65a Email: christian(a)quelltextlich.at 4040 Linz, Austria Phone: +43 732 / 26 95 63 Fax: +43 732 / 26 95 63 Homepage: http://quelltextlich.at/ ---------------------------------------------------------------

Attachments:

signature.asc (application/pgp-signature — 490 bytes)

Show replies by date

Bartosz Dziewoński

5 Jun 5 Jun

4:12 p.m.

On Thu, 05 Jun 2014 15:36:07 +0200, Christian Aistleitner <christian(a)quelltextlich.at> wrote:

...

The image data in the data uri scheme decodes to images from VectorBeta [3] like: VectorBeta/resources/typography/images/search-fade.png VectorBeta/resources/typography/images/tab-break.png VectorBeta/resources/typography/images/tab-current-fade.png VectorBeta/resources/typography/images/portal-break.png

These images are also part of the core Vector skin, where they sit at [mediawiki/core]/skins/vector/images. -- Matma Rex

Nuria Ruiz

9:23 p.m.

I can see those images in the CSS file that results after this call as background images on the default skin of es.wikipedia. They look correct in the CSS: http://bits.wikimedia.org/es.wikipedia.org/load.php?debug=false&lang=es… The likely explanation could be that there is some syntax issue (that only appears on windows?) on the data image path specified by us in the css and thus some less forgiving browsers are not interpreting the image in the css as a "data" url but rather as a regular one and then the url is composed as if it was a relative url (using the current domain) and fetched (or tried to fetch) That is, some browsers on windows are interpreting data urls as if they were like this: background-url:url('/some/relative/path') In any case that fetch should be a 404 so the thing we should probably think of fixing going forward is not counting 404 urls in pageviews. On Thu, Jun 5, 2014 at 6:12 PM, Bartosz Dziewoński <matma.rex(a)gmail.com> wrote:

...

On Thu, 05 Jun 2014 15:36:07 +0200, Christian Aistleitner < christian(a)quelltextlich.at> wrote: The image data in the data uri scheme decodes to images from

VectorBeta [3] like: VectorBeta/resources/typography/images/search-fade.png VectorBeta/resources/typography/images/tab-break.png VectorBeta/resources/typography/images/tab-current-fade.png VectorBeta/resources/typography/images/portal-break.png

These images are also part of the core Vector skin, where they sit at [mediawiki/core]/skins/vector/images. -- Matma Rex _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Matthew Flaschen

10:44 p.m.

On 06/05/2014 05:23 PM, Nuria Ruiz wrote:

...

I did a quick check, and Jigsaw (the W3C's validator) does complain about our data URLs on that page: http://jigsaw.w3.org/css-validator/validator?uri=https%3A%2F%2Fbits.wikimed… ----- .filehistory a img, #file img:hover Value Error : background url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAAAAAA6mKC9AAAAGElEQVQYV2N4DwX/oYBhgARgDJjEAAkAAEC99wFuu0VFAAAAAElFTkSuQmCC) is an incorrect URL url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAAAAAA6mKC9AAAAGElEQVQYV2N4DwX/oYBhgARgDJjEAAkAAEC99wFuu0VFAAAAAElFTkSuQmCC) repeat ----- I haven't done any background research (is this error new, do browsers care about this, is it just the data: protocol or something else , etc.). Matt Flaschen

S Page

6 Jun 6 Jun

6:39 a.m.

On Thu, Jun 5, 2014 at 3:44 PM, Matthew Flaschen <mflaschen(a)wikimedia.org

...

wrote:

...

I did a quick check, and Jigsaw (the W3C's validator) does complain about our data URLs on that page: http://jigsaw.w3.org/css-validator/validator?uri=https% 3A%2F%2Fbits.wikimedia.org%2Fes.wikipedia.org%2Fload.php% 3Fdebug%3Dfalse%26lang%3Des%26modules%3Dext.gadget.a-commons-directo% 252Cimagenesinfobox%252CrefToolbar%7Cext.uls.nojs%7Cext.visualEditor. viewPageTarget.noscript%7Cext.wikihiero%7Cmediawiki.legacy. commonPrint%252Cshared%7Cmediawiki.skinning.interface%7Cmediawiki.ui. button%7Cskins.vector.styles%26only%3Dstyles%26skin% 3Dvector%26*&profile=css3&usermedium=all&warning=1&vextwarning=&lang=en ----- .filehistory a img, #file img:hover Value Error : background url(data:image/png;base64,iVBO[blahblah]) is an incorrect URL url(data:image/png;base64,iVBO[blahblah]) repeat

The Jigsaw CSS validator complains about any data URL inside url() unless it's in quotes. The snippet .filehistory a img,#file img:hover{ background:white url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAAAAAA6mKC9AAAAGElEQVQYV2N4DwX/oYBhgARgDJjEAAkAAEC99wFuu0VFAAAAAElFTkSuQmCC') repeat; background:white url(// bits.wikimedia.org/static-1.24wmf7/skins/common/images/Checker-16x16.png?20…) repeat!ie } passes with the added quotes. Stackoverflow [1] thinks this a bug in Jigsaw, but regardless why would the CSS generate bogus requests in a cross-section of browsers? "some less forgiving browsers" doesn't normally include 60% Firefox 29 and 31% Chrome 35. If it's only es and pt, I wonder if it's something else in the bits.wikimedia response that makes the browser try to interpret the charset in the data URI as other than charset=US-ASCII . I don't know of a charset that would not interpret these ASCII characters as ASCII. Besides the other theories advanced, might it be sporadic ResourceLoader mis-minification? What's the HTTP Referer for these requests, can we tell if it's coming from an external <link rel > to CSS or CSS a mw.loader.implement() piece of JavaScript inserting the CSS? [1] < http://stackoverflow.com/questions/15481088/are-unquoted-data-uris-valid-in…

...

-- =S Page Features engineer

Federico Leva (Nemo)

12:41 p.m.

It's not specific to es and pt, it's easy to spot such URLs in any stats.grok.se top pages report: http://stats.grok.se/de/top Nemo

Christian Aistleitner

9 Jun 9 Jun

7:58 a.m.

Hi, On Fri, Jun 06, 2014 at 02:41:07PM +0200, Federico Leva (Nemo) wrote:

...

It's not specific to es and pt, it's easy to spot such URLs in any stats.grok.se top pages report: http://stats.grok.se/de/top

That URL is (currently) for March data, and characteristics changed considerably since then. In all of June, we have only 2 affected requests for dewiki in the sampled 1000 stream. We're always having such background noise. But eswiki has 2648, and ptwiki 1378 affected requests. Eswiki and ptwiki together amount to 93% of the affected skew data uri requests in June, but only to ~2% of all requests. So for current data, it is specific to eswiki and ptwiki. Have fun, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Kefermarkterstrasze 6a/3 Email: christian(a)quelltextlich.at 4293 Gutau, Austria Phone: +43 7946 / 20 5 81 Fax: +43 7946 / 20 5 81 Homepage: http://quelltextlich.at/ ---------------------------------------------------------------

Christian Aistleitner

1:34 p.m.

Hi, On Thu, Jun 05, 2014 at 11:39:28PM -0700, S Page wrote:

...

[ Jigsaw CSS validator over-complaining ]

Full ACK. Especially, the relevant data uris like data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAAuCAIAAABmjeQ9AAAARElEQVR42mVO2wrAUAhy/f8fz+niVMTYQ3hLKkgGgN/IPvgIhUYYV/qogdP75J01V+JwrKZr/5YPcnzN3e6t7l+2K+EFX91B1daOi7sAAAAASUVORK5CYII= match the specification's regular expressions for unquoted url characters [1]. That said ... while standard conformance is nice here, if others have the feeling that we should quote them nonetheless, I do not see an issue with quoting them.

...

Besides the other theories advanced, might it be sporadic ResourceLoader mis-minification?

I had tried loading the resources several times from different servers, but that didn't bring up anything useful.

...

What's the HTTP Referer for these requests, can we tell if it's coming from an external <link rel > to CSS or CSS a mw.loader.implement() piece of JavaScript inserting the CSS?

The referer is empty for ~97% of affected requests. The chain of requests looks like this: 1. Client fetches some page (like http://pt.wikipedia.org/wiki/Copa_do_Mundo_FIFA ) 2. Client fetches resources for this page (like http://bits.wikimedia.org/pt.wikipedia.org/load.php?[...] with referer http://pt.wikipedia.org/wiki/Copa_do_Mundo_FIFA ). 3. Client fetches urls with data uri appended (like http://pt.wikipedia.org/wiki/data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA… with empty referer). Thanks, Christian [1] Well ... both of them. In [2] (normative) the regular expression [!#$%&*-\[\]-~] is used while [3] (also normative :-/ ) uses [!#$%&*-~] . So they differ in \ handling. But regardless of the choice of the above variants, the above url is matched by any of them. [2] http://www.w3.org/TR/CSS21/syndata.html#tokenization: [3] http://www.w3.org/TR/CSS21/grammar.html#scanner -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Kefermarkterstrasze 6a/3 Email: christian(a)quelltextlich.at 4293 Gutau, Austria Phone: +43 7946 / 20 5 81 Fax: +43 7946 / 20 5 81 Homepage: http://quelltextlich.at/ ---------------------------------------------------------------

Brad Jorsch (Anomie)

3:33 p.m.

On Mon, Jun 9, 2014 at 9:34 AM, Christian Aistleitner < christian(a)quelltextlich.at> wrote:

...

2. Client fetches resources for this page (like http://bits.wikimedia.org/pt.wikipedia.org/load.php?[...] with referer http://pt.wikipedia.org/wiki/Copa_do_Mundo_FIFA ). 3. Client fetches urls with data uri appended (like http://pt.wikipedia.org/wiki/data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA… with empty referer).

Just out of curiosity, are there any non-data URLs referred to from the CSS loaded in step 2, and if so do they also lack referer when fetched in their equivalent to step 3? -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

Christian Aistleitner

9:26 p.m.

Hi, On Mon, Jun 09, 2014 at 11:33:12AM -0400, Brad Jorsch (Anomie) wrote:

...

On Mon, Jun 9, 2014 at 9:34 AM, Christian Aistleitner < christian(a)quelltextlich.at> wrote:

Just out of curiosity, are there any non-data URLs referred to from the CSS loaded in step 2, [...]

For Firefox 29 and Chrome 35: No, I could not find any :-( Those client sessions do not show requests for the CSS fallback images or the like. Thanks, Christian P.S.. For the other outlier browsers, we see such requests and also refers. But there requests are all over the place, and it seems to me that the outlier browsers are just generally choking badly on the served CSS. Like for example a session coming with a User-Agent header from iBrowser/2.7, requesting en.m.wikipedia.org/wiki/data:image/png (with Referer: http://en.m.wikipedia.org/wiki/Main_Page ) but also en.m.wikipedia.org/wiki/bottom,color-stop(0, en.m.wikipedia.org/wiki/Top,left en.m.wikipedia.org/wiki/linear-gradient( (each with Referer: http://en.m.wikipedia.org/wiki/Main_Page ) But those are just a hand-full of requests. I'd write those off as outliers. -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Kefermarkterstrasze 6a/3 Email: christian(a)quelltextlich.at 4293 Gutau, Austria Phone: +43 7946 / 20 5 81 Fax: +43 7946 / 20 5 81 Homepage: http://quelltextlich.at/ ---------------------------------------------------------------

Christian Aistleitner

11:09 p.m.

Hi, On Mon, Jun 09, 2014 at 11:26:35PM +0200, Christian Aistleitner wrote:

...

On Mon, Jun 09, 2014 at 11:33:12AM -0400, Brad Jorsch (Anomie) wrote:

On Mon, Jun 9, 2014 at 9:34 AM, Christian Aistleitner < christian(a)quelltextlich.at> wrote:

Just out of curiosity, are there any non-data URLs referred to from the CSS loaded in step 2, [...]

For Firefox 29 and Chrome 35: No, I could not find any :-( Those client sessions do not show requests for the CSS fallback images or the like.

Mhmmm ... but then again, although most resources linked in the CSS get served through bits, eswiki's and ptwiki's CSS also has a few images that get served from the upload cluster. We would not see such requests for upload cluster images linked in the CSS as the upload cluster's cache logs do not yet flow into Hadoop. :-/ Have fun, Christian -- ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ---- Companies' registry: 360296y in Linz Christian Aistleitner Kefermarkterstrasze 6a/3 Email: christian(a)quelltextlich.at 4293 Gutau, Austria Phone: +43 7946 / 20 5 81 Fax: +43 7946 / 20 5 81 Homepage: http://quelltextlich.at/ ---------------------------------------------------------------

3633

days inactive

3637

days old

wikitech-l@lists.wikimedia.org

Manage subscription

10 comments

7 participants

tags (0)

participants (7)

Bartosz Dziewoński
Brad Jorsch (Anomie)
Christian Aistleitner
Federico Leva (Nemo)
Matthew Flaschen
Nuria Ruiz
S Page