I have a page that includes a dynamic js-script depending on the page I'm visiting. However, I'm getting errors in my log from some IE8-visitors, where it seems like the actual request-url is completely mangled for the mentioned script.
This is what it should fetch:
<script type="text/javascript" src="?partial=filterjs&json=true&viewall"></script>
which translates to /sv/5/outlet?partial=filterjs&json=true&viewall
However, looking in my logs, I see stuff like:
/sv/5/outlet?partial=filterjs&json=truepor</a></li></ul></h2></li><li%20class=
/sv/7/jackor?partial=filteent/view/teams
It seems to truncate the url, and append random stuff from the actual markup that comes later on (way later on, in fact, although approx at the same offset)
I first thought it had something to do with the new XSS-filter that IE8 implemented, but tried disabling it using the HTTP-header
X-XSS-Protection: 0
Without success.
I cannot reproduce this error on my own machine either, however this happens several times a day (on a site with approx 3000 visits per day). This is happening on both XP, Vista and Win7 according to the user-agent (NT 5.1, 6.0 and 6.1).
Anyone recognize this behaviour?
Yes, this is a known bug in the lookahead downloader in Internet Explorer, where it drops a 4k part of the page when doing lookahead downloads.
This sometimes means that an URL for a resource in the page is cut and combined with some other text later in the page, resulting in a bad URL being requested.
The lookahead downloader is only used to try to fill the cache beforehand, when the resource is actually needed in the page it will be requested with the correct URL, so the user doesn't experience any errors in the page because of this.
Related
This is really, really weird. I developed a site offline using Apache / Strawberry Perl / Firefox. It displays data in object tags as expected, calling data from external sites.
Upload the code to server, and it will display objects where the code is on the same site ... but refuses to "pull" in data from other domains, (which I own)
If you try "http://demo.coadmem.com/members" and click on a circle on the left, a product listing appears, (served from same domain) but the ones from "cbwizard.cristofayre.com" and "cristoafayre.com/poppa" on same page refuse to appear. Yet when I set up a test using YouTube, it loads OK.
I asked the host if there was some sort of "block" that stopped the objects from loading external site, and of course their response was "we can see no problems reported in the error logs".
Also, at "http://coadmem.com/admin", there is another object at the top - which works fine offline, but from server displays a white empty "about" bar!!.
Here are two of the codes I'm using: (the cb-wizard one uses a bit of javascript to select a random keyword; too much to add here, so please view source code. Anyone see a glaring error as to why it won't work online?
<object data="http://www.cristofayre.com/cgi-bin/poppa/banner_ad.pl?u=1:aa00" width=480 height=90></object>
<object style="position:fixed;top:0px;width:100%;height:20px;" width="100%" height="20px" data="http://www.cristofayre.com/cgi-bin/admin_ad.pl?t=w"></object>
I know the scripts work, 'cos if you type the data line into a browser, the correct HTML is displayed; it just refuses to appear when on the server!
I'm wondering if there is some sort of "list" that the host might be applying that allows the majors such as Google / Youtube to be loaded into iframes / objects, but disallows 'minor' sites. (The suport team didn't seem to know anything about such a list)
** I also wondered if the "same-origin" policy is coming into play, but surely it shouldn't as that defeats the whole point of using iframes and objects in the first place.
I was "sort of" right. It wasn't that certain URL's were being blocked, rather that the frames were set up ONLY to show data that originated from the same domain as the browser was set too, (don't ask me how the YouTube iframe circumvented this rule, but there you go!)
As you can see from the above comments, the solution was to create a .htaccess file and use the command "Header always unset X-Frame-Options" which in simple terms (that I can follow) is saying "Whatever the header for the X-Frame-Option is set to, ignore it! and display the data anyway"
Perhaps this might help someone in a similar dilemma. It was certainly baffling as to why the ActiveState / Strawberry Perl version worked OFFLINE, but not online.
I've recently got an email from Google, saying that they are going to ban my AdSense account because I'm sending Personally Identifiable Information to them with my Google AdSense tag requests. It says that around 1% of requests from my website have a referrer of:
some_user#my_website.com/some/subpage
and they consider some_user#my_website.com to be PII (even though it can be completely made up abcd1234#my_website.com). More on this here: https://support.google.com/adsense/answer/6163366?hl=en .
I never link to this kind of URLs (the only form I use is my_website.com/some/subpage), but I guess my users sometimes enter it manually (since product-wise my website is providing an email service, it may seem reasonable by some logic).
I figured URI of some_user#my_website.com/some/subpage is legal since http basic auth allows for specifying user like this. When I entered it manually to Firefox, some_user# disappears from the location bar but in the Net panel of Firebug I can see all files are indeed requested from some_user#my_website.com/some/subpage and that's how Google sees it too.
I though that as a brute-force solution even something like:
if uri contains '#':
redirect to my_website.com
would do.
I'm using NGINX/UWSGI/Python Paste + JS. I've tried to implement the above condition both on server side and in JS, but my URI always says my_website.com/some/subpage even if I manually put some_user#my_website.com/some/subpage in the browser address bar.
I've also tried configuring basic_auth in NGINX to disallow providing any user but with no effect.
How do I get rid of these requests?
How do I get the FULL URI (with some_user#) in JS? I tried document.URI and window.location.href but they didn't contain the user part...
Apparently presence of user# part in the URI can be detected by examining window.location.href. I haven't noticed it before since window.location.href only contains user# in Webkit-based browsers (e.g. Chrome, Opera, Safari) but not in Firefox!
To resolve the problem I've added a check on that in JS + a JS redirect to an URL without user[:password]#.
Hopefully Google uses the same variable to figure out referrer for the ad requests, so it get PII only from Webkit browsers & fixing it for Webkit suffices. Will keep you posted.
I have an AJAX post that retrieves data from the server and either replaces part of the page or in some cases the full page. This is controlled by a javascript fullRefresh parameter. The problem is the refresh code works find in Firefox but causes a Permission Denied error in the bowels of JQuery after it runs in IE although it would appear to actually replace the page contents successfully.
IE version 11.0.9600.16659
JQuery version 1.8.2
Error message
Unhandled exception at line 2843, column 3 in http://localhost:62761/Scripts/jquery-1.8.2.js
0x800a0046 - JavaScript runtime error: Permission denied
My code is
function RefreshScreenContent(formActionUrl, formHTML, fullRefresh) {
fullRefresh = (typeof fullRefresh === "undefined") ? false : fullRefresh;
if (fullRefresh) {
document.write(formHTML);
document.close();
}
else {
$("#content-parent").html(formHTML);
}
}
The partial refreshes work fine but the full refreshes are the problem. I have tried hardcoding the document.write call to write a well formed simple html page rather than formHTML in case that was somehow the problem but even a simple single word page causes the error.
The actual error occurs a some point later with a callback inside JQuery.
The AJAX post to the server is in the same application i.e. is not a cross domain request. I have seen posts online talking aboue cross domain stuff that is not applicable here.
Can anyone tell me why this is happening and how to stop it? Is there an alternative IE way of replacing the page contents?
Your code is fine (at least at first glance). My guess is that you make the call in such a way, that it is interpreted as cross-domain.
I would suggest checking:
http vs https (most common)
the destination port
the root url
maybe the "destination" page makes some requests of its own, check to be on same domain
The reason why IE may be the only one with the problem is that it has higher security demanding by default that other browsers (check advanced security settings - can't remember where they are put in menu) so it interprets requests in a more "paranoid" manor.
I repeat, what I said is just a guess, based on cases I've been put into.
In the end I used the approach here to replace the body tag in the pgae with the one in the markup the AJAX receives back https://stackoverflow.com/a/7839921/463967
I would have preferred to replace all content not just the body but I can always adapt later to include the header etc as body is enough for my uses right now. This works in IE and Firefox.
I have a page that is being continually reloaded, about every 45 seconds. If I disable javascript in the browser, the page stops reloading - so I suspect that some javascript is the culprit. But there's a large amount of it scattered across various .js files, some of them compressed. So I'm having a hard time poring thru the JS source trying to find the culprit.
I'm looking for ideas on how to find the cause - without reading (and understanding) all of the JS source.
I've tried using Break on Next in Firebug. It always breaks inside of jquery.min.js - but there's no history in the stack, so I can't tell who called jQuery.
The web page is http://www.sarasotasailingsquadron.org/
Other ideas?
Alright, so I have found part of your problem. I can't quite find where it originates, but maybe this will help you.
I haven't been able to completely reproduce your issue under Chrome, but every minute or so, I do see a request for your home page. According to Chrome's developer tools, that request is initiating within jQuery. (That doesn't mean jQuery is the culprit... that just means that whatever code is making the request is using jQuery to do it.)
In the console, there is a suspicious error message:
Resource interpreted as Image but transferred with MIME type text/html: "http://www.sarasotasailingsquadron.org/".
The call stack drops it down to $.transition. It seems that this has to do with your image transition header, "coin slider".
I've skimmed your code and don't see the reference, but somewhere I suspect you are trying to load your home page as an image in that header. Maybe you have some invalid HTML or a null URL to the image keeping it from populating the full request URL or something. In any case, this should help you track down the exact source.
So I'm toying around with HTML 5 and the localStorage and I'm noticing that my values only get stored when I run the page in Firefox on the local host (i.e. http://127.0.0.1:8000/test/index.html), but when I run the file locally (file:///C:/test/index.html) my values don't get stored. Safari 4 has no problems with both setups.
So does anybody know if this is by design -> DOM Storage on the Mozilla Developer Center
(Firefox 2 permitted access to storage
objects higher in the domain hierarchy
than the current document. This is no
longer allowed in Firefox 3, for
security reasons. In addition, this
proposed addition to HTML 5 has been
removed from the HTML 5 specification
in favor of localStorage, which is
implemented in Firefox 3.5.)
Or if there is a workaround?
I wonder because offline storage that works only online sounds silly :P
If anybody wonders, the code is as easy as it gets:
function save()
{
localStorage.setItem('foo','bar');
}
function load()
{
var test = localStorage.getItem('foo');
alert(test);
}
It seems a bug: Bug 507361 - localStorage doesn't work in file:/// documents
Hope is fixed soon!
2011-09-13: Bug fixed, implemented in 'Mozilla8'. I tested this with Firefox 8 and it works now.
Well, the linked document does say that
localStorage is the same as globalStorage[location.hostname], with the exception of being scoped to an HTML5 origin (scheme + hostname + non-standard port)
I don't want to claim that I understand 100% what that means, but the bit in brackets would suggest that the URL needs to have certain properties - in particular that the scheme and hostname are what Firefox considers an HTML 5 origin. I suspect that file:/// URLs don't match this, while your http://127.0.0.1/ does.
edit: Looking at the W3C's description of the Origin property, step 7 looks like it might be causing the problem. Depending on how the localStorage handling is implemented, it may be expecting a 3-tuple as returned by step 12, but for a file:// URL the return value may be just about anything.
So, er, I suppose it is by design. On reflection, chances are that this isn't really by design; there's no reason why localStorage shouldn't work for file:// URLs. It might just be a case of the output of one browser-specific implementation not matching the expectations of another.
As for workarounds, would globalStorage not do what you want here?
As of Oct 5 2020, localStorage on Firefox seems to be broken again. Try this:
Download Mozilla demo page: https://mdn.github.io/dom-examples/web-storage/
Change the animal/color to something other than default.
close the page's tab (or the browser).
Download the page again. It's back to defaults. (Firefox 81:0 et.al.)
Even worse, if you do step 1 & 2 above and then open another copy of the demo in a new tab, not only does the new tab not get the saved data, but the original demo page (refresh it) has gone back to the defaults; as though the new tab STEPPED on the saved data.