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:
- We are using Splunk to track
- Happens with multiple data-URIs
- Happens on all browsers
- On multiple pages throughout our site
- Our QA has not been able to duplicate the issue
- Below are the results from a specific data-URI
- Relevant CSS file - (http://c.mfcreative.com/lib/tgn/combo.ashx?14/css/v1/main.css)
- Unminified version of same file - (http://c.mfcreative.com/lib/tgn/combo.ashx?14/css/v1/main.css&minify=false see line 35
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
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.
来源:https://stackoverflow.com/questions/17279643/why-would-css-data-uris-be-logged-as-404-requests