Actions
Issue #1627
closedStory #1150: As a user, I can lazily fetch repositories
mod_xsendfile and the Django WSGI application are setting the content type incorrectly.
Start date:
Due date:
Estimated time:
Severity:
2. Medium
Version:
Platform Release:
2.8.0
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Pulp 2
Sprint:
Quarter:
Description
I noticed this as part of the "browse a repository with a web browser" work (https://pulp.plan.io/issues/1512). We're responding with a content type of text/html:
[vagrant@dev ~]$ curl -v -k "https://dev.example.com/pulp/repos/zoo/gorilla-0.62-1.noarch.rpm"
* Trying 127.0.0.1...
* Connected to dev.example.com (127.0.0.1) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* ALPN, server accepted to use http/1.1
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
* subject: E=root@dev,CN=dev,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--
* start date: Feb 01 14:00:37 2016 GMT
* expire date: Jan 31 14:00:37 2017 GMT
* common name: dev
* issuer: E=root@dev,CN=dev,OU=SomeOrganizationalUnit,O=SomeOrganization,L=SomeCity,ST=SomeState,C=--
> GET /pulp/repos/zoo/gorilla-0.62-1.noarch.rpm HTTP/1.1
> Host: dev.example.com
> User-Agent: curl/7.43.0
> Accept: */*
>
* skipping SSL peer certificate verification
* NSS: client certificate not found (nickname not specified)
* ALPN, server accepted to use http/1.1
* skipping SSL peer certificate verification
* ALPN, server accepted to use http/1.1
< HTTP/1.1 200 OK
< Date: Wed, 03 Feb 2016 19:01:14 GMT
< Server: Apache/2.4.18 (Fedora) OpenSSL/1.0.2f-fips mod_wsgi/4.4.8 Python/2.7.10
< Last-Modified: Tue, 02 Feb 2016 21:22:46 GMT
< ETag: "994-52ad01a568438"
< Content-Length: 2452
< Content-Type: text/html; charset=utf-8
<
This, of course, makes the browser try its best to render an RPM as html (I snipped that from the above demo). Surprisingly, yum and company seem to handle this fine, but a browser doesn't. We need to (somehow) make sure the content type is set correctly. There may be a setting in mod_xsendfile. If not, we'll need to do it in the WSGI application.
Actions
Attempt to guess the MIME type of content served with xsendfile.
This is mostly for the benefit of browsers, since the default MIME type Django uses is text/html which causes the browser to attempt to render RPMs and such instead of downloading them.
closes #1627