404 errors caused by import command - solved!

MSIE 6.0 downloads cause 404 error

[pcunix]

I have been annoyed for quite a while now by errors like this in my logs:

202.xx.xx.#*$! - - [10/Dec/2007:11:14:47 +0000] "GET
/Basics/Permissions_files/reset-fonts-grids.css HTTP/1.1" 404 6832 "http://example.com/Basics/perms.html" "Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)"

Until this morning, I did not make the connection between the fact that all of these were css files I am using @import for and that the offending browser is always MSIE 6.0

Well, duh: it's users downloading web pages! And MSIE 6.0 must get confused by "@import".

I fixed it with this in .htaccess:

RedirectMatch permanent (.*)/.*_files.*css$ /safedown.html

[edited by: SuzyUK at 3:06 pm (utc) on Dec. 10, 2007]
[edit reason] examplified & edited URLs [/edit]

[SuzyUK]

pcunix, thanks for posting this

can I just ask exactly how you were using the @import, it used to be the case that using the bracketed version or using quotes caused errors or was misread by IE - though tbh I can't remember which did what, it may be that one of the ways still causes log errors?

e.g.
@import url(path/to/mystyle.css);
@import url (path/to/mystyle.css);
@import "path/to/mystyle.css";

the last one is the one I use mostly and can be used as a method of hiding from IE4 (not that that is altogether necessary any more) - also I see to remember there being something about the version with the space in it being a problem..

anyway I though it might be interesting to see if the error could also be fixed just by changing the syntax for those that have no access to .htaccess

-Suzy

[jdMorgan]

I've seen these errors as well, but using this alternate form:

<link rel="stylesheet" type="text/css" href="style.css">

Rather than trying to redirect the .css requests to an HTML file (which normally won't work), I just added a fix-up routine to my .htaccess code. Something like:

# Fix up broken MSIE 6 "Save page as" .css path requests
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/4\.0\ \(compatible;\ MSIE\ 6\.0;\ Windows
RewriteRule _files/([^/]+/)*([^.]+\.css)$ /$2 [L]

However, it would be much more interesting to find out if there is a stylesheet inclusion method that MSIE 6 does handle properly.

Jim

[pcunix]

Why wouldn't my Redirect work? Not being argumentative, just curious..

[pcunix]

Suzy, what I have is a mix:

@import "/reset-fonts-grids.css";
@import "/nslate.css";
@import url(http://www.google.com/cse/api/branding.css);

And now I see in my logs that IE has never screwed up with "branding", so maybe that is another way to fix it..

[jdMorgan]

Basically, browsers "know" that html files can not be directly "included" inside other html files, while images, css, and external JavaScripts can be included.

If your include of an html file instead of a css file actually worked, then the browser would try to render the main html file using the included html as a stylesheet, and that certainly would not work.

Jim

[edited by: jdMorgan at 5:03 pm (utc) on Dec. 10, 2007]

[pcunix]

But that's not what's happening: IE is trying to do a GET on the mangled name - I don't think it is trying to "include" anything; it just wants to save the files it thinks are being referenced.

[jdMorgan]

Think about when the visitor tries to 'view' the saved page image using his/her browser, though...

Jim

[pcunix]

Shouldn't matter a bit: yes, he's missing the style sheets, but he was missing them with the broken download anyway.

But yes, I see that if you want to give him everything he should get, then your fixup rewrite would be better.. in my case, I think I'll leave it as I did it because I think most of the people downloading are probably stealing content.. no sense being extra nice to them!

[SuzyUK]

think I understand what Jim is saying, but cmiiw, you are including (or redirecting to) an HTML file which gives the visitor no more than an error message, slightly more than a a broken download would do anyway - thus only saving yourself a line in the error log?

And now I see in my logs that IE has never screwed up with "branding", so maybe that is another way to fix it..

Well that could be interesting as that particular sheet (branding.css) is called via a different format/syntax. However, I would also point out (the obvious?) that that stylesheet is coming from a different server. So to test the differing syntax method I would try the same format but using an absolute path to your own server [ i.e. @import url(http://www.yourserver.com/path/to/stylesheet.css) ]

have no idea why except that is another difference to test/try? and you never know..

[pcunix]

Well, my goal is to eliminate lines in the error log because I review that every day looking for things I might have screwed up so getting rid of hundreds of errors is important to me..

As I said, I'm not that concerned with the downloader getting my style sheets.. but it would be interesting to find out if there is a way around this for all conditions.