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
Related
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
Our php-driven website has recently added ssl certificates to support the https protocol and we are having problems with IE6 through IE8 although our pages do not have resources called through http.
I have read this post : http://paulirish.com/2010/the-protocol-relative-url/
So, basicaly, I need to replace all the
background: url('/images/whatever.gif');
With :
background: url('//www.mydomain.com/images/whatever.gif');
I'm not quite a fan of using my domain name across several hundred css files to start with, but suppose I do : what would be the best practice to do so for my development, test and staging environments which are all on different subdomains than the production site. I would need to use dynamic representations of the domain name in the css files, most probably driven from some sort of config file, but how ?
You don't have to add your hostname to use protocol-relative URLs. The form you're already using is protocol-relative, because it doesn't specify a protocol.
Can you detail the problems you are having? Have you confirmed with a test that the URL with a domain name will solve your problem?
PS: If you have hundreds of CSS files, you'll probably be happier with a dynamic generation system anyway, but that's a separate matter.
The problems are popups in IE6, 7, 8 that say there is mixed content in the page (which should be http resources included in an https page). Chrome, FF4 and up and IE9 do not show those popups, and this is correct. There are no http included resources.
Several blog posts seem to point to background urls as the source of this problem. One of the posts (http://blogs.msdn.com/b/ieinternals/archive/2009/06/22/https-mixed-content-in-ie8.aspx) has a comment from Eric Law at MSFT, who states :
The debugger reports that the following is the URL that is triggering
the prompt:
"about:/images/lightview/inner_slideshow_play.png"
Of course, that URL doesn't actually exist in your markup. It looks
like there's dynamic creation of an IFRAME and injection of content
into that frame. The default URL for an empty frame is about:blank,
which leads to the prompt.
and ...
Other quirks to be aware of: In IE6, we treat "about:blank" as
insecure content, as well as "javascript:" and "res:". In IE7, we
fixed the "about:blank" case, but we have not (yet) changed javascript
and res.
So the problem is known and confirmed by MSFT for their older browsers, which create an IFRAME and inject content that then generates the error.
Most workarounds I have stumbled upon point to using protocol-relative urls, like in the first url I showed. I'm not sure you can consider 'background: url('/images/whatever.gif');' as a protocol-less call, because of this infamous IE6 to 8 bug.
--Edit : Working on a solution. We have found this in our javascript files and it seems it has been the real problem from the beginning :
<input target="_blank"class="sub" type="button" style="background-image:url(../images/name.gif);">
Ok ! Got it.
By the way, if ever anybody runs accross the need to find exactly what problems they are having with IE6, IE7 or IE8 on https webpages that are incorrectly reported as containing mixed content, use this script : http://www.enhanceie.com/dl/scriptfreesetup.exe
So in the end it was the button I talked about in the last post. Changing it to an imported class, swapping background-image for just background and getting rid of the ../ at the beginning did the trick.
Thanks all for your help, I'll still flag an answer on Ned's input, since it was of some help.
I'm really hoping that someone can help. I have tomorrow to get this right or we're in trouble. I apologise as I only have the details from memory, being at home.
The error is this:
Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.
Details: Error parsing near '
<!DOCTYPE html P'.
It appears in both FF and IE so far, and only happens on the live servers.
It occurs within partial (or attempted partial as they stop working and don't update) postbacks within an update panel on a form that is on every page. It doesn't always do it, but once it's broken, it's consistent. I have a suspicion that it kicks in after the pages in question have been posted back to by another page, but I'm not 100% about this. This form is absolutely integral to the function of the site.
I've googled and googled, and I've seen the lists of the usual causes (Reponse.Write, tracing etc.) as well as the not so usual causes (e.g. firewalls messing with headers), but none seem to apply, plus some doubly do not apply because this issue does not occur at all on our staging server. I don't know if slower load times would affect it.
Any help would be greatly appreciated!
Edit: I'm using .net 2.0 and the ajax framework 1.0.
Thanks to Greg for his comment, but in the end I found the issue - which is indeed one of the culprits in several posts regarding this that I had looked at previously, but I missed! It was my Output Caching causing the problem, and though we've since looked at more aspects of the caching, this particular issue was fixed by a) turning off the caching (obviously!) or b) setting VaryByParam="*". Further info here: <Removed by OP, dead link>
I have an asp.net C# .net 3.5 page which contains several user controls. I am noticing that sometimes the html loaded on the browser is incomplete. It seems to get cut-off.
Any suggestions on how to troubleshoot whats the root cause?
This can be symptomatic of server errors or proxy problems. I would use Fiddler to check what's going back and forth between your browser and the server. If you are getting any 500 (server error) response codes, that would be a good place to look.
Another thing to check would be javascript errors on the page, because depending on what your javascripts are doing, errors can prevent loading of other content in some cases.
womp probably has most of the bases covered, but the other angle that can lead to issues like this would be exceptions getting eaten but causing processing to stop, thereby sending half the page or somesuch.
Verify that your HTML is being written to the page by viewing the source code of the page after it loads. My guess is that the HTML that is being output is invalid, and that the browser isn't able to properly display it. Make sure all your HTML tags are properly closed and balanced.
It could also be an issue with the request being ended midway through. Try removing one control at a time from the page and see if the situation improves. If it does, you'll know which control is to blame.
It is quite unlikely that it is the same problem, but I had that happen before where the page had a custom filter attached to response.filter which reformatted the output to fix up some dotnet SEO problems. And the one we wrote had a bug where one regular expression consumed a bit too much copy in some instances and broke the output
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.