Safari 4 doesn't load stylesheet

The problem is simple; as I’ve mentioned before your server is sending the wrong content-type for the stylesheet, so it can’t interpret your CSS file as a stylesheet.

Judging by the name of the current content-type (‘addtype’), it sounds like the server hasn’t been set-up correctly. You’ll be able to correct this easily yourself if you’re using Apache using mod_rewrite. If you’re using IIS, it’s impossible unless you have admin permissions (which I assume you don’t).

I appreciate the information and have passed it on the the web hosting company’s technical support team. I hope it helps them troubleshoot the issue. Other browsers (including earlier versions of Safari) seem to be able to ignore this problem and load the style sheet anyway. I guess the new Safari is less forgiving of errors of this type.

Here is the response I received from the web hoster’s technical support:

Every thing appears to be in order. My browser did see that the .css file should be processed as a style sheet “Accept text/css,/;q=0.1”

If you would like mod_rewrite is installed and running on your hosting account. You can add directives into a .htaccess file in your account if you would like to use mod_rewrite to modify the way that some requests to our web server are handled

Response Headers

Date
Mon, 22 Jun 2009 15:19:02 GMT
Connection
keep-alive
Server
Apache
Etag
“b260ccc-2ad1-46cb3a9d50840”
X-lori-time-2
1245683942481
Request Headers
Host
dsdogs.com
User-Agent
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR
3.5.30729)
Accept
text/css,/;q=0.1
Accept-Language
en-us,en;q=0.
Accept-Encoding
gzip,deflate
Accept-Charset
ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive
300
Connection
keep-alive
Referer
http://dsdogs.com
X-lori-time-1
1245683941800
If-Modified-Since
Fri, 19 Jun 2009 13:40:11 GMT
If-None-Match
“b4260ccc-2ad1-46cb3a9d50840”
Cache-Control
max-age=0

Aside:- That’s strange since for the GET request for the stylesheet, my Accept field reads ‘text/html,application/xhtml+xml, application/xml;q=0.9,/;q=0.8’.

Your support guy however, failed to mention the content-type that he’s receiving (which is the field to get right, in this case); I’ve just checked and it’s still listed as ‘addtype’ - this is the field that needs to be changed.

However, I’m still clueless as to why I’m seeing different media types in the Accept, compared to what the support guy is seeing

As had been suggested in this thread, an .htaccess file containing the line “AddType AddType application/x-httpd-php .css” was causing .css files to be sent to the webrowser as “addtype”. Commenting out the line solved the problem. Thanks to everyone who responded.

When you access a file directly, the browser (in most cases) will use the default “Accept” header. Because the agent (browser) doesn’t know what the content is until it gets “Content-Type” returned from the server. Now in the case of Scripts, Link, Style, and Image elements the agent is given a hint to what the resource type is. Therefore it can adjust the “Accept” header to better handle those.

Hope that explains that little difference.

Fiddler a must tool for any web developer doing HTTP inspections!

Thanks for clearing that up, logic_earth; that’s a lot more clear now. I’ll have to check out that tool- I’m currently using the HTTP Headers plugin

Unfortunately looks like Windows platform only. Is there an equivalent utility for the MAC?

I’m not aware of anything equivalent of Fiddler for the Mac side of things. However, if you have a Windows Machine either physical or virtual you could do this: http://www.fiddler2.com/fiddler/help/hookup.asp#Q-NonWindows

Hello,

My problem is similair to emos’s problem.
I am experiencing problems with the Safari browser (and only with Safari),
when loading my web page.
The problem I have is that safari shows my page in different looks,
because it does not always seem to load all css files (I have 7). When
you press the refresh button, things tend to get worse. When you
reload the page by hitting return in the url field, you probably get
to see the page in good shape.

Thanks for any hints,
Stiti

Make sure your cache is cleared and then check your server settings.

If it’s not fixed from that then we will need a link :).

You should have really made your own thread however.