Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use the same mimetypes as pypi does #42

Closed
wants to merge 1 commit into from
Closed

Conversation

rmohr
Copy link

@rmohr rmohr commented Jan 3, 2014

it seems that since pip>=1.5, pip checks the response header of archives for Content-Encoding.

This is what pypiserver currently guesses when you try to download a tar.gz archive:

('Content-Type', 'application/x-tar')
('Content-Encoding', 'gzip')

What pip now does is decompressing the archive because of the Content-Encoding, without removing the .gz. Then it tries to untar it. Because of the filename it tries to decompress the tar archive again.

This is what pypi returns:

$ wget -S https://pypi.python.org/packages/source/p/pytz/pytz-2013.9.tar.gz 
  [...]
  Content-Type: application/x-gzip
  Accept-Ranges: bytes
  [...]

The patch below returns the same types as pypi does.

@schmir
Copy link
Contributor

schmir commented Jan 3, 2014

thanks for your pull request. I do think the same behaviour can be achieved by calling mimetypes.add_type.
pypiserver.core already calls this in order register a mimetype for .egg files.

Do you have the time to update your patch make core.py register the mimetypes instead?

@bauer1j
Copy link

bauer1j commented Jan 3, 2014

This has broken my build setup as well. Would love to have this fixed as soon as possible. Thanks for a great tool.

schmir added a commit that referenced this pull request Jan 3, 2014
this basically removes the content-encoding header.

many thanks to @rmohr for reporting this issue in
#42:

,----
| it seems that since pip>=1.5, pip checks the response header of archives
| for Content-Encoding.
|
| This is what pypiserver currently guesses when you try to download a
| tar.gz archive:
|
| ('Content-Type', 'application/x-tar')
| ('Content-Encoding', 'gzip')
|
| What pip now does is decompressing the archive because of the
| Content-Encoding, without removing the .gz. Then it tries to untar
| it. Because of the filename it tries to decompress the tar archive
| again.
|
| This is what pypi returns:
|
| $ wget -S https://pypi.python.org/packages/source/p/pytz/pytz-2013.9.tar.gz
|   [...]
|   Content-Type: application/x-gzip
|   Accept-Ranges: bytes
|   [...]
|
| The patch below returns the same types as pypi does.
`----
@schmir
Copy link
Contributor

schmir commented Jan 3, 2014

I've released pypiserver 1.1.4, which contains a workaround for this bug in pip. thanks again @rmmohr.

@schmir schmir closed this Jan 3, 2014
@rmohr
Copy link
Author

rmohr commented Jan 19, 2014

@schmir, thanks for fixing this so fast, and a much more elegant patch than mine 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants