Skip to content
This repository has been archived by the owner on Nov 1, 2023. It is now read-only.

Setting content-type creates a second entry instead of replacing default #141

Closed
nickramsbottom opened this issue Sep 17, 2019 · 1 comment

Comments

@nickramsbottom
Copy link

nickramsbottom commented Sep 17, 2019

We are using the following configuration:

{
  "root": "_site",
  "headers": {
    "/**": {
      "Access-Control-Allow-Origin": "*",
      "Surrogate-Control": "max-age=60, stale-while-revalidate=60, stale-if-error=86400",
      "Cache-Control": "max-age=0, no-cache, must-revalidate"
    },
    "/some-path": {
      "Content-Type": "application/json"
    }
  }
}

/some-path has the following response headers:

< HTTP/1.1 200 OK
< Connection: keep-alive
< Server: nginx
< Date: Tue, 17 Sep 2019 12:57:39 GMT
< Content-Type: application/octet-stream
< Content-Length: 524
< Last-Modified: Tue, 17 Sep 2019 10:52:53 GMT
< Content-Type: application/json
< Etag: "5d80bb05-20c"
< Accept-Ranges: bytes
< Via: 1.1 vegur
<

The original content-type header is returned as well as the one we have added.

@edmorley
Copy link
Member

edmorley commented Jun 9, 2022

Hi

This buildpack is now deprecated and we are recommending people move the more actively maintained heroku-buildpack-nginx. For migration advice see here.

As such, I'm closing this issue out since we won't be making further changes to this buildpack.

@edmorley edmorley closed this as not planned Won't fix, can't repro, duplicate, stale Jun 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants