IE Not using redirected URL for resolving relative URLs - css

I have a servlet that generates CSS for a given colorScheme name if it exists in the database. However, should the colorScheme not be found, it issues a response.sendRedirect() to the location of the actual file on our CDN.
This works in all browsers except for IE when the CSS contains relative links to images for icons, backgrounds, etc. Every other browser uses the redirected URL (CDN url) to resolve the relative URLs in the CSS file, but IE still uses the original request URL (servlet URL).
I can't change the relative URLs to absolute URLs in the CSS files for a number of reasons I can't go in to. Is there a way to get IE to use the redirected URL instead of the request URL for the relative URL resolution?

Sounds like more of a code design problem. Personally I don't rely on IE to do anything as it should. It always lets me down :(. I would always include your CSS from the CDN at the begining of the head using the HTML LINK tag, then let the JS import overwrite it afterword. This way your website will also look decent in noscript browsers.

As a workaround you can use css #import tag instead of redirecting to the external css file.
#import url('http://www.example.org/style.css');

Since we are processing our HTML/JS in another servlet before the call to the colorScheme servlet, what I did was check to see if the requested skin was dynamic (from the servlet) or not at this stage. If the colorScheme is dynamic, I write out the link tag with the address of the CSS servlet, otherwise I write out the address of the CDN.

Related

#import CSS not working

I am using the Chargify service and within their settings they allow you to include some custom CSS. I am including
#import url(http://swag-box.herokuapp.com/chargify.css);
I can see that the CSS is being embedded into the page but It doesn't seem to be affecting the page in anyway.
You can view the live page here.
What exactly is the problem here?
Using #import is not necessary. You can just do:
<link rel="stylesheet" type="text/css" href="//swag-box.herokuapp.com/chargify.css">
The use of // makes the request use the same scheme as the page. In your case the page scheme is https. However, you were including via http. Some browsers will considre this unsafe and block the resource. That is why you were not seeing the import (it was working). You can of course change the #import to use https or //.
You can also update the browser settings to allow the unsafe resource to be loaded, but this is a per-user setting. If you are using Chrome, you will notice a shield to the left of the favorites star.
No quotes are required in the url declaration for #import.
EDIT: always use https

CSS background-image won't show with short URL

I've done my searching and the topics haven't been of help.
I'm trying to have the background image of my header repeat across the X axis of the header div.
When I make CSS with a long URL such as
background-image:url('http://site.com/images/logo.png'); everything works fine
When I try to shorten the CSS to something such as ~/images/ or even having the CSS and site file already in the root folder and using /images/ I get nothing
background-image:url('~/images/logo.png')
background-image:url('/images/logo.png')
This is possibly because you're not shortening your URLs appropriately.
Assuming an absolute path of:
url('www.example.com/images/imageName.png');
A root-relative URL would be:
url('/images/imageName.png');
And a relative path (assuming your CSS file is in www.example.com/css/cssStylesheet.css) would be:
url('../images/imageName.png'); /* parent directory, then the images directory */
The ~ prefixed url format is unknown to me, though I suspect it's an ASP, or .NET, form? Though I'm unable to advise on that.
Questions that might be of use to you:
How do I turn a relative URL into a full URL?
Using relative URL in CSS file, what location is it relative to?
Absolute urls, relative urls, and...?
A URL containing "~" is something that's specific to ASP.NET, it's processed server-side and transformed into a "proper" URL such as http://mysite/my_virtual_directory/images/logo.png. Web Browsers don't have any way to do this as they don't know to what "~" refers.
You need to ensure that the URLs you use in your CSS file are "understandable" by the browser, so either have them "fully qualified" (http://mysite/my_virtual_directory/images/logo.png) or starting from the "beginning" (/my_virtual_directory/images/logo.png).

WebRequest retrieved site loads different then original

I am using WebRequest to retrieve a html page from the web and then displaying it using Response.Write.
The resulting page looks different from the original mostly in font and layout.
What could be the possible reasons and how to fix it?
Most probably, the HTML you retrieve contains relative URLs for loading images, stylesheets, scripts. These URLs are not correct for the page as you serve it from your site. You can fix this by converting all of the relative URLs into absolute URLs or by including a BASE tag in the head of the HTML, pointing to the URL of the original page.
Be advised though that deeplinking to images and other resources is considered bad practice. The source site may not like what you are doing.
The reason might be that the original html page contains relative (to the original site) paths to the stylesheet files so when you render the html in your site it cannot find the css.
Does the remote web site include CSS, JavaScript, or images?
If so, are any of the above resources referenced with relative links (i.e.: /javascript/script.js)?
If so, when the browser receives the HTML from your server, the relative links (which were originally relative to the source server) are now relative to your server.
You can fix this by either changing the HTML to use absolute links (i.e.: http://www.server.com/javascript/script.js). This is more complicated than it sounds: you'll need to catch <link href="..."/>, <a href="..."/>, <form action="..."/>, <script src="..."/>, <img src="..."/>, etc.
A more limited solution would be to place the actual resources onto your server in the same structure as they exist on the original server.
The remote site might look at the User-Agent and serve different content based on that.
Also, you should compare the HTML you can retrieve from the remote site, with the HTML you get by visiting the site in a browser. If they are not different, you are probably missing images and/or css and javascript, because of relative paths, as already suggested in another answer.

How do tools like the web dev toolbar get the entire css file of a site?

The web dev toolbar for Firefox is quite an impressive tool.
What I am completely clueless about is how does this tool get the css stylesheet file of a site? This is hosted on a host which is secure etc. I am completely stumped.
I must be thinking about this in all the wrong way.
Thanks
The client (in this case Firefox) has to download the CSS file in order to render the page correctly. The plugin (in this case Firebug) simply requests the proper URL and the browser it gets it--most likely from the cache. There is no real mystery here.
In every HTML file, there's a link to the CSS stylesheet, or else the browser wouldn't know where to find it, thus losing the ability to render the page correctly.
It's in the form of <link rel="stylesheet" type="text/css" href="theme.css">,
I'd like to add that regardless of whether the host is 'secure' or not, it still is presenting the file to the client.
Unless, of course, you're looking at a XML file. Then you need to consult the XSL which'll tell you where the stylesheet is.

What might cause CSS to fail to load occasionally on all browsers?

I'm working on a webapp, and every so often we run into situations where pages will load without applying CSS. This problem has shown up in IE6, IE7, Safari 3, and FF3.
A page refresh will always fix the problem.
There are 3 CSS files loaded, all within the same style block using #import:
<STYLE type="text/css">
#import url([base css file]);
#import url([skin css file]);
#import url([generated css path]);
</STYLE>
In any situation when we take the time to examine the html source, nothing is out of the ordinary. Access logs seem normal as well - we're getting HTTP 304 responses for the static CSS files whenever they are requested, and an HTTP 200 response for our generated CSS.
The mimetype is text/css for the css files and the generated css. We're using an iPlanet server, which forwards requests to a Tomcat server.
davebug asked:
Is it always the same css file not loading, or is the problem with all of them, evenly?
None of the CSS files load. Any styles defined within the HTML work fine, but nothing in any of the CSS files works when this happens.
I've had a similar thing happen that I was able to fix by including a base style sheet first using the "link rel" method rather than "#import". i.e. move your [base css file] inclusion to:
<link rel="stylesheet" href="[base css file]" type="text/css" media="screen" />
and put it before the others.
if it happens often enough that you're able to see it in your browser, try intalling the Live http headers Firefox extension or the Tamper Data extension, and watch the response headers as they are seen by the browser.
I don't know why, but in my case if the page is loaded from an action with the path like /ActionName, I see this problem.
But if I change it (for example) to /reservedArea/ActionName or /aPath/ActionName it works :/
It's crazy...
Examining the headers is a good idea, but I imagine all you will learn from them is that the server didn't respond to a request every once in a while.
I see this happen all the time on the net. Images won't load until you refresh, css is messed up, etc. All of the situations are solved by a refresh.
I imagine one way you could "fix" this, maybe, is by specifying in your cs file a url for an image for some element. Then, on page load in javascript, get that element and see if that image has loaded. If not, then have the page reload itself.
Seems pretty exotic, but that's the only idea I had...
Use ab or httperf or curl or something to repeatedly load the CSS files from the webserver. Perhaps it's not consistently serving the pages.

Resources