Release assets served using wrong content type

[zoul]

Some users report not being able to download the handbook (sample). Could it be a problem of serving the wrong content type? We appear to set the content type correctly in the workflow file, but when downloading the asset is served as application/octet-stream:

$ curl -vL https://github.com/cesko-digital/derisking-handbook/releases/latest/download/handbook.pdf
> GET /cesko-digital/derisking-handbook/releases/latest/download/handbook.pdf HTTP/1.1
> Host: github.com
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 302 Found
< Date: Fri, 07 Feb 2020 08:33:52 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Server: GitHub.com
< Status: 302 Found
< Vary: X-PJAX
< Location: https://github.com/cesko-digital/derisking-handbook/releases/download/v1.0.6/handbook.pdf

* Connected to github.com (140.82.118.4) port 443 (#0)
> GET /cesko-digital/derisking-handbook/releases/download/v1.0.6/handbook.pdf HTTP/1.1
> Host: github.com
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 302 Found
< Date: Fri, 07 Feb 2020 08:33:52 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Server: GitHub.com
< Status: 302 Found
< Vary: X-PJAX
< Location: https://github-production-release-asset-2e65be.s3.amazonaws.com/204700622/796c8180-41bd-11ea-9c87-e6afa2290ed3?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20200207%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200207T083352Z&X-Amz-Expires=300&X-Amz-Signature=1c04529b34158ed185fd97eb0c13fb5b2f1661c2f1cbea0d7dc0956927d0f466&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dhandbook.pdf&response-content-type=application%2Foctet-stream

* Connected to github-production-release-asset-2e65be.s3.amazonaws.com (52.216.228.16) port 443 (#1)
> Host: github-production-release-asset-2e65be.s3.amazonaws.com
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< x-amz-id-2: HGkbNnZzD1eMy/YVH+RFPatMilA0ljjyJ2plhXwn1ruQwvaFhqVQskwcczQe/cIVr455FJPV/Rg=
< x-amz-request-id: 2C954DFAD37E4CB4
< Date: Fri, 07 Feb 2020 08:33:53 GMT
< Last-Modified: Tue, 28 Jan 2020 11:01:04 GMT
< ETag: "3e4799641829e24a10d8404dc5cdcd0a"
< Content-Disposition: attachment; filename=handbook.pdf
< Accept-Ranges: bytes
< Content-Type: application/octet-stream
< Content-Length: 815076
< Server: AmazonS3

The response-content-type argument in the second request is interesting. Are we doing this wrong?™

[zoul]

The content type seems to be right when looking at the asset through the API:

$ curl https://api.github.com/repos/cesko-digital/derisking-handbook/releases/assets/17624226
{
  "id": 17624226,
  "node_id": "MDEyOlJlbGVhc2VBc3NldDE3NjI0MjI2",
  "name": "booklet.pdf",
  "label": "",
  "uploader": {…},
  "content_type": "application/pdf",
  "state": "uploaded",
  "size": 794823,
  "download_count": 325,
  "created_at": "2020-01-28T11:01:04Z",
  "updated_at": "2020-01-28T11:01:04Z",
  "browser_download_url": "https://github.com/cesko-digital/derisking-handbook/releases/download/v1.0.6/booklet.pdf"
}

But then downloading the browser_download_url returns application/octet-stream:

$ curl -vL https://github.com/cesko-digital/derisking-handbook/releases/download/v1.0.6/booklet.pdf 2>&1| grep Content-Type:
< Content-Type: text/html; charset=utf-8 # redirecting to AWS
< Content-Type: application/octet-stream # final response

Same thing happens with the EPUB version. I’ve submitted a support ticket to see if this is the expected behaviour, the ticket ID is 553020.

[zoul]

(I have received no updates about the submitted support ticket since the original submission some three weeks ago, so I have just submitted another one to push forward, #579645.)

[zoul]

OK, since GitHub is giving us the finger here and GitHub Releases is not the perfect distribution mechanism for this anyway, we have pivoted to serving the release assets from our own server (see 1ec95be).