Closed Bug 1216804 Opened 9 years ago Closed 9 years ago

delivery: Set Content-Type when uploading to S3 (Clicking a link *.txt in archive.mozilla.org downloads it. It should be open in browser.)

Categories

(Cloud Services :: Operations: Miscellaneous, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: alice0775, Assigned: oremj)

References

Details

(Keywords: regression)

Steps to reproduce
1. Open http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win32/1445374431/ for example
2. Click link "firefox-44.0a1.en-US.win32.txt"

Actual Results:
Download

Expected Results:
Open in browser. It worked in http://ftp.mozilla.org
Flags: needinfo?(nthomas)
Keywords: regression
at Step2, the server returns Content-Type : application/octet-stream in the response header.
this is wrong. 
Content-Type should be text/plain; charset=UTF-8 .
Yes, this is a regression from bug 1211732.

For *.txt.gz, which is buildbot logs, we currently have
 Content-Type: text/plain; charset=UTF-8
 Content-Encoding: x-gzip
 Access-Control-Allow-Origin: *

In the new system we have just
 Content-Type: application/octet-stream

Other file types (.zip, .dmg, .tar.bz, .mar) may be worth setting too.
Blocks: 1211732
Component: Release Automation → Operations
Flags: needinfo?(nthomas)
Product: Release Engineering → Cloud Services
QA Contact: bhearsum
Summary: Clicking a link *.txt in archive.mozilla.org downloads it. It should be open in browser. → delivery: Set Content-Type when uploading to S3 (Clicking a link *.txt in archive.mozilla.org downloads it. It should be open in browser.)
Assignee: nobody → oremj
Content-Type is fixed. Do we definitely want the CORs headers?
Flags: needinfo?(nthomas)
Nevermind, I've enabled CORs for GET.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(nthomas)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.