ContentType - text/css for css files in 304 Not Modified

i want nginx to include ContentType text/css for css files in 304 Not
Modified request

here is the headers for the static css file request. you can see that
there
is no ContentType sent.

GET /static/fan.css HTTP/1.1
Host: A.B.C.D
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
If-Modified-Since: Wed, 01 Sep 2010 20:07:45 GMT
Cache-Control: max-age=0

HTTP/1.1 304 Not Modified
Server: nginx/0.8.49
Date: Wed, 01 Sep 2010 20:15:51 GMT
Last-Modified: Wed, 01 Sep 2010 20:07:45 GMT
Connection: keep-alive
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000

I can also confirm that in nginx config i have included mime.types which
has
the following:

text/html                             html htm shtml;
text/css                              css;

Hello!

On Wed, Sep 01, 2010 at 01:23:38PM -0700, kevin wrote:

i want nginx to include ContentType text/css for css files in 304 Not
Modified request

here is the headers for the static css file request. you can see that there
is no ContentType sent.

RFC 2616 says about 304 responses:
(http://tools.ietf.org/html/rfc2616#section-10.3.5)

If the conditional GET used a strong cache validator (see section
13.3.3), the response SHOULD NOT include other entity-headers.
Otherwise (i.e., the conditional GET used a weak validator), the
response MUST NOT include other entity-headers; this prevents
inconsistencies between cached entity-bodies and updated headers.

Content-Type is entity header and not listed above this paragraph,
so clearly qualifies as “other entity-headers”.

Could you please clarify why you think RFC is wrong here and you
need Content-Type in 304 response?

Maxim D.

On Wed, Sep 1, 2010 at 4:39 PM, Maxim D. [email protected] wrote:

so clearly qualifies as “other entity-headers”.

Could you please clarify why you think RFC is wrong here and you
need Content-Type in 304 response?

it is for a facebook app, and i do not have control over this. without
this
header the css file is not processed as css at all.

I’d offer to try disabling Last Modified header from your nginx and give
reasonable high (30 days?) value in Expires header.

Meanwhile you may report this error to whoever is assuming that absence
of Content-Type is reason for not processing your css (facebook or
facebook app developers, I’m not sure who you’re talking about but IMHO
they all will at least comment on RFC position about this).

If you’ll look at different servers sending 304 than you’ll see that
google for example does not send Content Type. As well as apache.org
It’s perfectly valid and accepted practice.

Alex.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs