I can see this site.com/assets/css/screen.css?954d46d92760d5bf200649149cf28ab453c16e2bwhat is this random alpha numeric vales question mark ? i don't think it's taking some value to use or what is it about ?
edit : also on refreshing page the alpha-numeric value is same.
It is for preventing the browser from caching the CSS. When a CSS is requested by some browsers, specifically Internet Explorer, the browser will have a local copy of the CSS.
When a request is given to a server as:
site.com/assets/css/screen.css?skdjhfk
site.com/assets/css/screen.css?5sd4f65
site.com/assets/css/screen.css?w4rtwgf
site.com/assets/css/screen.css?helloWd
The server at site.com sees only:
site.com/assets/css/screen.css
And gives the latest version. But when the HTML page is requesting the browser to fetch the CSS as: site.com/assets/css/screen.css, for the first time, it fetches from the site.com server. There are many possibilities that the content might be changed in the meantime when the next request is sent. So programmers generally add a ?and-some-random-text, which is called Query String. This will force the browser to get a new copy from the server.
Some more detailed explanation:
It is a well known problem that IE caches too much of html, even when
giving a Cache-Control: no-cache or Last-Modified header to
everypage.
This behaiviour is really troubling when working with querystrings to
get dynamic information, as IE considers it to be the same page
(i.e.: http://example.com/?id=10) and serves the cached version.
I've solved it adding either a random number or a timestring to the
querystring (as others have done) like this
http://example.com/?id=10&t=2009-08-06_13:12:56 that I just ignore
serverside.
Is there a better option? Is there another, cleaner way to acomplish
this? I'm aware that POST isn't cached, but it is semanticaly
correct to use GET here.
Reference: Random Querystring to avoid IE caching
Related
I have a JSON resource, let's call it /game/1, which is being publicly cached with a long duration. Based on some client-side logic, I want to occasionally want to refresh this resource (for instance, when I know something should be happening server-side - a game ending, in my case).
Once refreshed, I would like all downstream caches to update with the new content, so any requests to /game/1 will fetch the refreshed content. Appending a querystring with a random parameter won't work in this case.
I have tried adding the following headers on the request, which seems to work in a temperamental fashion in browsers other than IE:
headers['Cache-Control'] = 'max-age=0, no-cache';
headers['Pragma'] = 'no-cache';
Using these headers, Chrome seems to sometimes refresh the content, presumably based on some internal heuristics.
Does anyone have any better ideeas for what I'm trying to achieve?
Try setting meta http-equiv="expires" content to zero.
Setting the 'expires' metatag to zero should force the browser to reload everything on each page visit. Forcing constant cache deletion will obviously slow down page loading (if all browsers obey it!) but maybe that's an acceptable trade-off. This won't help with downstream caches however, so it's far from a complete solution.
I'm setting a cookie during http GET request of the .html pages with embedded images. I'm expecting the browser to return the cookies when getting all the embedded images, but apparently it does not happen for the first embedded image.
Is this how it's supposed to work or am I missing something ?
Make sure the domain name matches your domain and that you've set a valid expiration date/time for it. These are the 2 most common mistakes.
It would help if we knew how you were setting the cookies. Note that NRNR's response is a bit misleading - he/she's right about the domain, but there's no requirement to set an expiration. However you will get varying results unless you explicitly set a path too - even if it's just '/'.
Browsers do vary a lot in how they handle all sorts of things, including cookies - so I wouldn't be too surprised if there are browsers out there which start retrieving additional content before the response headers for the referencing html page are processed. This is not how its supposed to work though.
C.
Original Question:
We have an odd error with WebResource.axd url generation. (It does not seem to be related to the fairly common "WebRsource.axd Padding is invalid and cannot be removed" issue).
We have an ASP.NET web page that, when created, adds a script reference to WebResource.axd.
In this case, we're seeing that the WebResource.axd link occasionally turns into garbage past a certain point, replaced by what looks like javascript. Worse yet, the url generation failure seems to be inconsistant.
In our case, the link should (and usually does look like):
/WebResource.axd?d=D-wd7RbHCvSp_p0mHAmE4g2&t=633464867255568315
All well and good. However, we are getting errors logged from users...and the url they're trying to access looks like (in one case):
/WebResource.axd?d=D-wd7RbHCvS/../../images/icons/Ico_resize.gif')}}function%20ShowFilter_Manufacturer(){var%20div.......
[the remaining encoded javascript from that link has been removed as irrelevant]
Stranger yet, we got a few of these in rapid succession from the same user, who was apparently trying to reload the page...each url slightly different.
/WebResource.axd?d=D-wd7RbHCvS<garbage>
/WebResource.axd?d=D-wd7RbHCvSp<garbage>
/WebResource.axd?d=D-wd7RbHCvSp_<garbage>
In some cases the garbage is encoded JavaScript, I've seen portions of a url...completely empty parameter strings...I don't see an obvious pattern.
As an aside, should it be relevant, it should be noted that I don't believe that this WebResource is anything other than a stock WebResource that is automatically included by .NET when certain features are included on a page...in this case, a field validator. Looking at the contents of the actual WebResource.axd reveals very standard looking set of Javascript functions that seem designed to handle generic .NET events. Not anything we've created.
Has anyone seen anything like this? (or better, has anyone understood why this was happening, and come up with a way to eliminate it?)
EDIT 0: Some additional information:
Item 1: In response to one answer, we made sure that our scripts are encased with CDATA tags, since our doctype is xhtml transitional:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Unfortunately, though we had high hopes, it does not seem to have solved the problem. We've noticed this more often with IE 8 as a browser, which would lend some credence to the idea that this is browser related...perhaps the way the browser is parsing the stream...but why we would get subtly different responses on subsequent attempts baffles me.
Item 2:
It turns out that the omitted sections seem to be blocks of fairly regular size. Someone reported that he was seeing 1k or 4k blocks missing, and I (so far...I've only looked at two cases thus far) would agree (mine were both missing 4096 bytes of data).
according to this post:
http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv
It seems that the problem is caused by the way browsers render pages differently when the doctype is not specified.
Here is another interesting post i found on this subject, still not the solution though:
http://blog.aproductofsociety.org/?p=11
on the above page it has "Response.Cache.SetNoStore()" as a possible solution in the comments, i'll try this next to see if it helps.
Microsoft has responded to this issue:
Note is a bug in Internet Explorer 8. The Internet Explorer team has been investigating this issue.
-=Impact=- Thus far, we believe the problem has no impact on the end-user's experience with the web application; the only negative effect is the spurious/malformed requests sent by the JavaScript speculative-download engine. When the script is actually needed by the parser, it will properly be downloaded and used at that time.
-=Circumstances=- The spurious-request appears to occur only in certain timing situations, only when a META HTTP-EQUIV tag containing a Content-Type with a CHARSET directive appears in the document, and only when a JavaScript SRC URL spans the 4096th byte of the HTTP response body.
-=Workaround=- Hence, we currently believe this issue can be mitigated by declaring the CHARSET of the page using the HTTP Content-Type header rather than specifying it within the page.
So, rather than putting
[META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8"]
In your head tag, instead, send the following HTTP response header:
Content-Type: text/html; charset=utf-8
Note that specification of the charset in the HTTP header results in improved performance in all browsers, because the browser's parsers need not restart parsing from the beginning upon encountering the character set declaration. Furthermore, using the HTTP header helps mitigate certain XSS attack vectors.
NOTE: There have been reports that this problem still happens when the META HTTP-EQUIV is not on the page. We will update this comment when we have more investigation.
Posted by Microsoft on 6/30/2009 at 12:25 PM
I am from the ASP.NET team -- we are looking for a customer willing to work with us on researching this issue. If anyone is able to reliably reproduce the problem by requesting their own pages and checking the logs, and is willing to work with our support group, please respond or send me a direct message. Thanks!
What version of .NET are you compiling against? What happens if you change your build to build for an older or newer version? (not sure if this would do anything but it's worth a try)
If it's still happening, I think you should post a bug about it on Microsoft Connect. They should come back to you pretty quickly.
Have you got any HttpHandlers or Modules that are registered in the web config that modify the rendered HTML before it's sent to the user?
These can often be:
Minifiying JS and CSS
Ensure HTML is valid
Might be worth a look.
This is an old post... but I've came across through a google search and reminded me of this...
http://www.troyhunt.com/2010/09/fear-uncertainty-and-and-padding-oracle.html
Could it have been related?
This was eventually fixed by Microsoft:
http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx
I asked a question on what is style.css?ver=1 tag?. I learned that developers use style.css?ver=1 to let browsers read updated css, but W.Craig Trader pointed out that is is not good.
My question is, what is the best way to force a browser to read updated css without style.css?Ver=1 format?
Your server should take care of it. It will tell the browser when the file was last modified, and if the browser's cache is out of date, it will download the new version.
More in depth, each time the page loads, the browser does a head request on each item in the page (stylesheets, images..), which the webserver responds to by only sending the HTTP headers without the body, there is a header that specifies when the file was last modified (and possibly more about cache control), and if the browser's cache has a version of the file older than what the webserver says it has, it reloads that content.
An option is to version the filename, like style-1.1.css.
Whenever we make changes to the CSS, it generally takes 24 hours to reflect those changes on my site. I have tried clearing the server cache and browser cache but it doesn't help too. Is there any other way to make the CSS changes reflect immediately after updation?
it happens in all the browsers... when i check it in the browser , i can access my css file with two paths eg : i store my css in folder named "Cssfolder" and my css name is say 135.css
So when i access the folder paths, Cssfolder/135.css & cssfolder/135.css, one of the path shows me latest css whereas other one shows me old css.Notice the "c" is captital in one path whereas small in other path.
Thanks.
I've found this to be a pretty common problem in a lot of my projects. I would suggest two things...
If it's just an app that you are working on you can use the CSS Cachebuster during development.
Following the idea behind the Cachebuster I have found that often adding the timestamp of the CSS file as a query string off of the CSS link will help in telling the browser that the file is different... something like... whatever.css?12212009035543
You might want to use a monitoring tool, like Live Http Headers for Firefox, to see the requests and responses to and from the server. This usually solves a lot of problems for me. Take a look at the "Expire" headers and conditional requests (like: "If-modified-since"). This said, take a look at server and client local times and timezones - it might be that they differ significantly and conditional GET requests "seem to be" handled correctly, because of future or otherwise mangled timestamps.
You can force to load the current css directly from the server with appending a random unique value to the url, like http://example.com/Cssfolder/135.css?983274928374 and http://example.com/cssfolder/134.css?08973249827. There's no way that this would ever get cached unless you use the same random value twice.
This way you learn where to look further for the solution to your problem: At the server, the ISP/a proxy or your browser.
You really need to see whether this is server side or client side. If the server is still serving the old CSS then clearly you've got no chance on the client side.
I've occasionally seen times where I've had to show the CSS in the browser, and then next time I've been to the real page, it's used that new CSS. Usually just hitting refresh does it.
Do you have any web caches like Akamai involved anywhere?
If you try to go to the CSS page from a computer which has never seen the old version, which version does it show?
EDIT: Changed answer to reflect edits in question.
I have been dealing with this issue in the past, and ended up writing a httpmodule to deal with it.
It's pretty simple, it just finds all script/css links in head tag (they now need to have runat=server) and appends the assembly version number to the link, in the same way as Tim K describes. This way im sure my clients always fetches the newest css/scripts when my app is updated in production, and never have to deal with this issue again.
Maybe Internet Service Provider cache, as in this case?
I was perplexed by this issue then someone said Ctrl+F5. Worked for me :)
When I am developing and I need to be sure that I am seeing changes as I work, I stick the css in the page ie
<style type="text/css">
/* your css */
</style>
Or you could constantly change the name of the css file itself, not very useful in a production environment, but perhaps okay while developing.
I know it doesn't solve the problem, but for developing it is okay.