Are Content-Type Response Headers Necessary?

Question

I am uploading content of various types (gif, jpeg, png, css, pdf) to amazon s3. And then I am placing Nginx in front of S3 so I can rewrite urls and have them pulled by azure cdn.

The problem I am running into is sometimes when files are uploaded (various ways but mainly javascript http upload) we often neglect to place the content types. I am trying to figure out if its worth the time to have nginx correct these headers via a serious of location and if statements or should i just remove all content type headers all together.

For example: When i look at this url in Chrome web inspector i dont see a content type header being returned. http://wiki.nginx.org/local/nginx-logo.png.

Are we finally at a point where browsers can themselves determine content types?

Does adding a content type header have any specific PERFORMANCE benefits?

What would be a quick nginx rule to set a content type based on file extensions? For example if the url is mydomain.com/s3reverseproxy/uploads/test.css?querystring=random to set its content type correctly? Current I am using this but worried that a lot of if statements are probably a bad idea:

    location ~* ^/s3/(.*) {


  # Headers based on file extensions
  more_clear_headers        'Content-Type';
  if ($request_uri ~* .*svg.*) {  
    more_set_headers        "Content-Type:image/svg+xml";
    more_set_headers        "X-Content-Type:OverRidden";
  }


  set $s3_bucket           'mybucket.s3.amazonaws.com';
  set $url_full            '$1';

  # HEADERS
  more_set_headers          "Server: PROXYS3";
  add_header                Cache-Control "no-transform,public,max-age=36720000";
  etag                      on;
  expires                   425d;
  .....

Thanks!

score 2 · Answer 1 · answered Apr 25 '14 at 00:19

2

All these types are usually stored in a file called mime.types, and they should be included by nginx.conf in the http context, instead of doing these extensive conditions, check the mime.types file, and add a record for each extension ( if it doesn't already exist ) and what type it's representing.

If they are all already included then make sure that your nginx.conf includes that file.

answered Apr 25 '14 at 00:19

Mohammad AbuShady

40,884
11
78
89

mime.types will not overwrite existing mime types when reverse proxying. Unless if I am doing something wrong? – Frank Apr 25 '14 at 01:42
sorry i don’t understand what you mean, overwrite what exactly? – Mohammad AbuShady Apr 25 '14 at 11:28
I mean that if the original header is wrong, when acting as a reverse proxy nginx will pass the incorrect content-type header. For example, if you upload a pdf file to Amazon S3 and set its content type header to blank or image/jpeg then when reverse proxying nginx doenst remove the header. We can strip the header, or correct it based on file extension, but I am trying to figure out if its worth the processing juice?. – Frank Apr 26 '14 at 22:42
1

some really need the header, like for example I remember that css files aren't processed by browsers if the content type text/css isn't sent, made me spend hours trying to find out why my css isn't working, but some other work right away, I think you could just test it and see what you need to add and what you don't. I don't know if there's a way to force nginx to force it's own headers over the ones that are coming from the server it self. – Mohammad AbuShady May 04 '14 at 19:51

Are Content-Type Response Headers Necessary?

1 Answers1