4

To reduce the number of requests across our site we are using CSS data-URIs rather than linking to external images. For some reason, these data-URIs are occasionally still being logged as a 404 request against our servers. Why would this be happening?

Random details:

Relevant CSS:

body{background:#e2decd url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAGuCAIAAADeSvtRAAAAfUlEQVQ4y9WTzQ7AIAiD+fr+rzzYSeOWGP+z7MABwVJstYiQmf02zvP3yrk2442Gqvijb9LT34tJ7vVP5u/zTBzDP113n/eYCv3ec1IOLGjn1bu9+K0zQEad/4r/iMj8dvLfVqetfcsf5X6z/y7ieuVk/SU19wMesxMXQMANapSO6rYFQnIAAAAASUVORK5CYII=) repeat-x 0 0}

Query to see all our 404 errors (there are 5 data-URIs in our top 10 404 errors):

sourcetype=iis* host=prd*ssscdn* sc_status=404 | top 100 cs_uri_stem

Query that generated the below image:

sourcetype=iis* host=prd*ssscdn* sc_status=404 cs_uri_stem="/lib/tgn/data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAGuCAIAAADeSvtRAAAAfUlEQVQ4y9WTzQ7AIAiD+fr+rzzYSeOWGP+z7MABwVJstYiQmf02zvP3yrk2442Gqvijb9LT34tJ7vVP5u/zTBzDP113n/eYCv3ec1IOLGjn1bu9+K0zQEad/4r/iMj8dvLfVqetfcsf5X6z/y7ieuVk/SU19wMesxMXQMANapSO6rYFQnIAAAAASUVORK5CYII="

Any help/direction at all would be much appreciated!

alt text http://www.jasonbuckboyer.com/playground/blah/data-uri-404-error1.png

Buck
  • 2,054
  • 2
  • 16
  • 19
  • Wouldn't data uri's start with data: instead of lib/ ? – Srikanth AD Jun 24 '13 at 16:41
  • if it has to do with url-rewriting, you should filter it not to be re-written, either on server or Splunk config (wich i do not know how to set up). sounds obvious i guess :) – G-Cyrillus Jul 02 '13 at 10:53
  • A client of mine is seeing this as well on a non-IIS server. the reason they're starting with /lib/tgn/ is because that's the relative path for the CSS file; were he(?) to put the CSS in his root, the data URI requests would come across as /data:image/png[...] – Doktor J Sep 12 '13 at 17:16

1 Answers1

1

I'm in some agreement with the comment Srikanth made. It looks to me like you have something in your code that is affixing /lib/tgn/ to the front of the url string, which ends up putting it before data to produce /lib/tgn/data:image/png, which is invalid.

You need to track that code down and have it ignore the string all together if it is a data uri, while still allowing it to append the image path to images that are saved and accessed in /lib/tgn/ directory.

Added Explanation

Based off your comment, I'm not sure we are quite communicating clearly. What I see in your above posted code for "Query that generated the below image" is this:

cs_uri_stem="/lib/tgn/data:image/png;base64,iVBORw0KGgo... [etc.]"

And the image you posted shows the cs_uri_stem values all having /lib/tgn/ inserted before the data:image/png. Something (perhaps your CDN combination, perhaps url rewrite rules on your server, or something else) appears to be causing that /lib/tgn/ code to be added into the css url() code at process/request time (since it appears that it is not being added directly into the CSS for neither your minified nor expanded code shows it added). But the end result your posted image is showing indicates the cs_uri_stem causing the 404 errors all have /lib/tgn/ added before the data:image/png. So the browser ends up not treating the url() as data because the request is starting with a path, namely /lib/tgn/data:image/png .... Since it believes it is looking for a file starting at path /lib/tgn/ then the browser is putting out a request that (of course) it will never get fulfilled, and thus a 404 error is generated.

Now maybe I am still not clear on what you were referring to in your comment, but perhaps I have made myself more clear as to what I believe your issue is.

ScottS
  • 71,703
  • 13
  • 126
  • 146
  • Our CDN automatically combines and minify files. When it goes through our combinator, we go to http://c.mfcreative.com/lib/tgn/combo.ashx?names-of-all-our-css-files. I've updated the URLs above to how this is in use on our production environment. Sorry should have done this initially. – Buck Jun 28 '13 at 15:54
  • I'm not quite sure we are communicating about the same thing exactly. I added further explanation in my answer, but I might still be misunderstanding some of what you intended to clarify in your comment. – ScottS Jun 28 '13 at 16:33
  • 1
    In your original answer I thought you meant that the `/lib/tgn/` was being added in the actual CSS file, which it is not. I don't think it has anything to do with server side rewrite rules since its behaving just like any other relatively included image would. But the bigger question question is why would it be processed as a server side request at all. It's like the browser is not recognizing the `data:image/png;base64,iVBORw0...` as a valid data-URI, so it is thus making a request to the server... – Buck Jun 28 '13 at 20:47
  • Well, my original answer was vague in that it appeared to be getting added _somewhere_ (could have been in the CSS or otherwise). You comment implies you _do_ have a server rewrite rule to add `/lib/tgn/`, correct? If so, that would explain why it is showing that, but I agree it would not then explain why a request is being made to begin with (that would be so only if it was being added to the CSS). – ScottS Jun 28 '13 at 22:44
  • @user1394692: Two more thoughts. One, another post online noted that [Google](http://www.coderanch.com/t/517060/Servlets/java/Mystery-url-data-image-png) (and theoretically other search engines) have at times done something that caused such an "addition" to the request string. Two, have you tried wrapping the request in quotes (`url('data: ...')`) to see if by chance it fixes the issue (maybe some improperly escaped character in the data string is triggering it to make the request)? – ScottS Jun 28 '13 at 23:15
  • To be clear, there are no rewrite rules here. More history - we initially had double quotes around our data-URIs. That caused even more 404 errors than we currently have. Even though that failed, we actually added single quotes around each of these data-URIs earlier today because that is how it is outlined here - https://en.wikipedia.org/wiki/Data_URI_scheme#CSS - We won't be able to test on our live servers for another week though. If this works while double quotes did not... then I am baffled. Especially since the spec says quotes are optional - http://www.w3.org/TR/CSS21/syndata.html#uri – Buck Jun 29 '13 at 06:26
  • Do you have a link you can share to the live site this happens with? – ScottS Jun 29 '13 at 14:02
  • [This page reports the bug.](http://trees.ancestry.com/tree?type=s) But again, none of our QA has actually seen this issue occur. The background image on the `` element has the data-URI in question. If it really did fail to load, the background should be a solid tan color. The data-URI is an image going from white to transparent over 430 pixels across the top of background. – Buck Jun 30 '13 at 05:11
  • I have no further ideas as to what might cause it. I really would have guessed rewrite rules (and maybe it still is, but not from you, rather from some other service, somewhat like the link I posted in an above comment about the issue with Google doing some kind of rewrite). If so, you could not "prevent" that request from occuring, you could only perhaps "handle" it on your end somehow. – ScottS Jul 04 '13 at 17:33