Cannot override Content-Type header for specific route

[termsflow]

Hi , I have several files in my webservice which are gzipped and should have content encoding header gzip, but at the same time they have different content types (js, wasm). If override their content type in route-headers section in staticwebapp.config.json it blindly ignores these changes and reset it to "application/gzip" in response header which leads to loading problems. I also tried to specify mimeTypes sections but it ignores as well. There is only one solution which helped me to set header "x-content-type-options": "" . But it works not in all browsers. It seems content type header somehow depends on encoding type, but it's very unclear how. Could you , please, explain how can I override content-types header for specific routes independently of encoding type.

[anthonychu]

Currently, if you request a file and there's a file with the same name plus a .br extension, we'll serve the .br file's contents with brotli compression (if supported by client). I don't think we do this for gzip if there's a matching .gz file but perhaps this is the right solution for this. I don't know if you can make this work using configuration.

@mkarmark what do you think?

[miwebst]

Hey @termsflow , do you mind sharing what you tried for the mimeTypes? I think there are a couple of bugs here that are causing this behavior :(

[termsflow]

Hi @miwebst , if I add the following mimeType section it doesn't change anything, the response remains the same.

[ivanvaladares]

I have the same issue. I can't override the content-type. Any news on this one @miwebst ?

[miwebst]

We are working on updating out logic for this. @ivanvaladares what file type is not working for you?

[ivanvaladares]

Thanks for getting back so quickly @miwebst The files I'm trying to serve are js and css, but they are gzipped. I need to change their content encoding and type on the fly. The following config is in place now:

{ "routes": [ { "route": "/images/*", "headers": { "cache-control": "must-revalidate, max-age=15770000" } }, { "route": "/dist/vendor.js.gz", "headers": { "cache-control": "must-revalidate, max-age=15770000", "content-type": "application/javascript", "Content-Encoding": "gzip" } }, { "route": "/dist/main-client.js.gz", "headers": { "cache-control": "must-revalidate, max-age=15770000", "content-type": "application/javascript", "Content-Encoding": "gzip" } }, { "route": "/dist/site.css.gz", "headers": { "cache-control": "must-revalidate, max-age=15770000", "content-type": "text/css", "Content-Encoding": "gzip" } } ], "navigationFallback": { "rewrite": "index.html", "exclude": [ "/images/*", "/dist/*" ] }, "mimeTypes": { ".js.gz": "application/javascript", ".css.gz": "text/css" } }

[rpgitrepo]

@miwebst - any update on overriding the content-encoding header as part of the routes for static web app instance?

[kaylumah]

I am attempting something similar with an feed.xml that should return content-type application/atom+xml but have not been able to hit on the correct syntax. Then I came across this issue

[kaylumah]

Attempted a few more things my self:

My previous configuration was the following (note does not work and outputs text/xml, presumably due to mimeTypes being present)

{
  "routes": [
    {
      "route": "feed.xml",
      "headers": {
        "Content-Type": "application/xml"
      }
    },
    {
      "route": "/feed",
      "redirect": "/feed.xml"
    }
  ],
  "mimeTypes": {
    ".xml": "text/xml"
  }
}

Then I attempt to set mimeTypes to feed.xml instead of .xml but got a json schema validation error there.

Finally I attempted

{
  "routes": [
    {
      "route": "/feed.xml",
      "headers": {
        "Content-Type": "application/xml"
      }
    },
    {
      "route": "/feed",
      "redirect": "/feed.xml"
    }
  ],
  "mimeTypes": {
    ".xml": "text/xml"
  }
}

The difference being the route is now called /feed.xml instead of feed.xml

For a few moments I was happy because it appeared to be working (at least on the Static Web App CLI), but after deploying it to the PR stage on GitHub it appears nothing was solved.

So unfortunately my "fix" is only available on the CLI.

@anthonychu Perhaps you can help with what I am missing. Presumably as a workaround I can set mime-type to application/xml for all XMLs. This would affect sitemap and atom RSS feed. But in reality I would want the feed to be application/atom+xml which is not a correct response type for the sitemap ofcourse

[anthonychu]

@mkarmark Is there a way to set the mime type for a single route?

[kaylumah]

anyone figure this out?

[MClauwaert]

We are also running into this problem. We are trying to modify content-type: text/css to content-type: text/css; charset=utf-8

[dev-sr201d]

Looks like this is still not fixed. The issue @MClauwaert posted creates warnings in all browser developer tools and lists as an error in W3C's official validator. Quite annoying if validation results are part of an acceptance documentation for a customer project.

[taraldr]

I'm trying to serve an extensionless file as text/json, but the result is application/octet-stream. Is support for this planned?

    ...
    "routes": [
        {
            "route": "/.well-known/openid-configuration",
            "headers": {
                "Content-Type": "text/json"
            }
        }
    ],
    ...

[jagoda]

I was able to modify the content type for a specific route using a combination of mimeTypes and URL rewriting. My understanding is that Static Sites uses the file extension to determine the content type. URL rewriting seems to allow the file to be served from a different URL while preserving the extension for the content type evaluation.

Example:

  "routes": [
    {
      "route": "/.well-known/apple-app-site-association",
      "rewrite": "/.well-known/apple-app-site-association.json"
    }
  ],
  "mimeTypes": {
    ".json": "application/json"
  }

Without this, /.well-known/apple-app-site-association was served as application/octet-stream regardless of the headers on the route.

[asbjornu]

Currently, if you request a file and there's a file with the same name plus a .br extension, we'll serve the .br file's contents with brotli compression (if supported by client).

@anthonychu while this seems to be working, I can't find this documented anywhere?

[krachynski]

I was able to modify the content type for a specific route using a combination of mimeTypes and URL rewriting. My understanding is that Static Sites uses the file extension to determine the content type. URL rewriting seems to allow the file to be served from a different URL while preserving the extension for the content type evaluation.

I was excited at first to find this workaround because I've been fighting with content-type for a few days now. It seems that this suggestion doesn't actually work. Instead of a file delivered as json, I get a 404 page.

This is super-annoying when it appears that all .well-known/ files seem to be delivered as json

[krachynski]

oh I finally clued in that the workaround does work if the files are on disk as *.json files.

Now to find a better document for rewriting a whole bunch of json files to remove the extension.