Forum: NGINX 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 Dounin

On Wed, Sep 1, 2010 at 4:39 PM, Maxim Dounin <mdounin@mdounin.ru> 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.