Nginx 是否需要内容类型响应头？

我正在将各种类型的内容（gif、jpeg、png、css、pdf）上传到AmazonS3。然后我把Nginx放在S3前面，这样我就可以重写url并让azurecdn将它们拉出来

我遇到的问题是，有时上传文件时（各种方式，但主要是javascript http上传），我们经常忽略放置内容类型。我试图弄清楚，是否值得花时间让nginx通过一系列位置和if语句来纠正这些标题，还是应该一起删除所有内容类型标题

例如： 当我在ChromeWebInspector中查看这个url时，我没有看到返回的内容类型标题

我们终于到了浏览器可以自己决定内容类型的时候了吗

添加内容类型标题是否有任何特定的性能优势

基于文件扩展名设置内容类型的快速nginx规则是什么？ 例如，如果url为mydomain.com/s3reverseproxy/uploads/test.css？querystring=random以正确设置其内容类型？目前，我正在使用它，但担心许多if语句可能是个坏主意：

    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;
  .....

---

谢谢

所有这些类型通常存储在一个名为

mime.types

的文件中，它们应该被

nginx.conf

包含在

http

上下文中，而不是执行这些扩展条件，检查

mime.types

文件，并为每个扩展添加一条记录（如果它还不存在的话）以及它所代表的类型

---

如果它们都已包含，请确保您的

nginx.conf

包含该文件。

mime.types在反向代理时不会覆盖现有的mime类型。除非我做错了什么？对不起，我不明白你的意思，覆盖什么？我的意思是，如果原始标题是错误的，当作为反向代理时，nginx将传递错误的内容类型标题。例如，如果将pdf文件上载到Amazon S3，并将其内容类型标题设置为空白或image/jpeg，则反向代理nginx时不删除标题。我们可以去掉标题，或者根据文件扩展名更正标题，但我正在试图弄清楚它是否值得处理。有些人确实需要标题，例如，我记得如果内容类型text/css未发送，浏览器不会处理css文件，这让我花了数小时试图找出css不工作的原因，但是马上做一些其他的工作，我想你可以测试一下，看看你需要添加什么和没有添加什么。我不知道是否有办法强迫nginx在来自服务器的头上强制自己的头。