johnsensible / django-sendfile Goto Github PK

sendfile depends on Unidecode that is GPL this means that sendfile and all other software that import it should be GPL too. Since unidecode is used only here:

https://github.com/johnsensible/django-sendfile/blob/master/sendfile/__init__.py#L80

would be possible to remove this dependency?

Would love the fix that landed in #37. Do you plan on cutting a 0.3.8 release any time soon or are you waiting for some more changes to come in?

It would be nice to offer a wheel package for django-sendfile releases.
See http://pythonwheels.com/

With Python 3.4, the Content-Disposition created by:

sendfile(request, path, attachment=True, attachment_filename='export.zip')

django-sendfile 0.3.10 is:

attachment; filename="b'export.zip'"; filename*=UTF-8''export.zip

(The call to str.encode() now returns a byte object: https://github.com/johnsensible/django-sendfile/blob/master/sendfile/__init__.py#L80)

django-sendfile 0.3.9 is (desired):

'attachment; filename="export.zip"'

I have no experience with writing python 2/3 compatible code so I have not attempted to create a pull request, yet.

Thanks for your work!

Hiya @johnsensible,

I found myself using your project in multiple projects and always enjoyed it. As far as I can see (issues, pull requests, stars, etc.) it's still quite popular but from the looks of it, also a bit abandoned. I'd hate to see the project die and would like to offer my help maintaining it, mainly sorting out current issues and pull requests, updating the compatibility/tests to work with new Python/Django versions, etc.

Feel free to have a look at my GitHub profile, where I have a couple of projects with a small userbases that I support. Nothing with the popularity of django-sendfile (in terms of stargazers that is ; ) but I am experienced with the 'worklfow' of an open source project, PyPi releases, etc.

Let me know what you think or if you have any questions.

We use this module since several years and it works perfectly.

Is status (according to pypi page) really "Beta"?

If you try to use sendfile with .gz or .tgz files, the response is given the Content-Encoding of "gzip" which causes the browser (or other client) to automatically decompress it on download.

.gz files should have no content-encoding and a content-type of 'application/x-gzip' and .tgz files should have no content-encoding and a content-type of 'application/x-compressed ', I think.

Django 2.1 and above has removed the permalink() decorator.

examples/protected_downloads/download/models.py contains @permalink

Just a note, in case you want to update your example application for modern versions of Django.

I have a usecase where I need to serve an entire folder on disk, only if the user has access to it. I can make the checks using a decorator or in the view. But can I configure this plugin to serve entire folders using X-Accel-Redirect, if the user is authenticated?

It works well when serving in terms of private, thanks. But I want the site staff members to access the private media uploaded by member, how should I config? Thanks.

The WSGI protocol specifies an optional mechanism for higher performance file transmission.

There is at least one wsgi server that implements this: uWSGI.

A backend that takes advantage of this mechanism would be very interesting. Is it possible to write one using the current API?

our code that was exhibiting the problem

return sendfile(request, remote_agent_installer, attachment=True, attachment_filename=filename, mimetype='application/octet-stream', add_encoding_header=False)

our work around:
we added another param to not add content encoding.

Python27/Lib/site-packages/sendfile/init.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Python27/Lib/site-packages/sendfile/init.py b/Python27/Lib/site-packages/sendfile/init.py
index da16a83..eaa0157 100644
--- a/Python27/Lib/site-packages/sendfile/init.py
+++ b/Python27/Lib/site-packages/sendfile/init.py
@@ -32,7 +32,7 @@ def _get_sendfile():

-def sendfile(request, filename, attachment=False, attachment_filename=None, mimetype=None, encoding=None):
+def sendfile(request, filename, attachment=False, attachment_filename=None, mimetype=None, encoding=None, add_encoding_header=True):
'''
create a response to send file using backend configured in SENDFILE_BACKEND

@@ -86,7 +86,7 @@ def sendfile(request, filename, attachment=False, attachment_filename=None, mime
response['Content-Type'] = mimetype
if not encoding:
encoding = guessed_encoding

• if encoding:
• if encoding and add_encoding_header:
  response['Content-Encoding'] = encoding

return response

Hi, I followed your documentation's suggestion to use django sendfile.

I'm French and as English persons we have some word with accentuation like a café.

It's rather common for us to have this kind of letters in file names, but here a stacktrace:

[my app things]
  File "/home/gunicorn/prod/ama/ama_prod/ama_app/models/site.py", line 186, in get_document
    return sendfile(request, self.file.path)

  File "/home/gunicorn/prod/ama/venv/lib/python2.6/site-packages/sendfile/__init__.py", line 59, in sendfile
    response = _sendfile(request, filename, mimetype=mimetype)

  File "/home/gunicorn/prod/ama/venv/lib/python2.6/site-packages/sendfile/backends/nginx.py", line 7, in sendfile
    response['X-Accel-Redirect'] = _convert_file_to_url(filename)

  File "/home/gunicorn/prod/ama/venv/lib/python2.6/site-packages/django/http/__init__.py", line 612, in __setitem__
    header, value = self._convert_to_ascii(header, value)

  File "/home/gunicorn/prod/ama/venv/lib/python2.6/site-packages/django/http/__init__.py", line 601, in _convert_to_ascii
    value = value.encode('us-ascii')

UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 40: ordinal not in range(128), HTTP response headers must be in US-ASCII format

note: my file name is péter_là_gueule.txt

Using django 1.5 and gunicorn with UTF-8 encoded filesystem.

The saving is done well but how to you override the default url display of the file to use the protected method?

Not sure whether this is just a documentation issue (i.e. it's supported by one of the other backends i.e. WSGI) or whether it's unsupported.

Sorry if it's obvious to others but this area isn't one of my strong points - hence why I'm looking for a nice abstraction library!

When I try to set up to sendfile with spanish characters (like: á, é, í, ó, ú...) using nginx backend, the link of sendfile response its: 404 not found.

Currently the pypi package downloads the django-sendfile files from Github. This can lead to issues in the deployment process (just happened for a project of mine, due to a temporary problem with a Github server).

It would therefore be better if you would upload the package directly to pypi, instead of simply relaying to the Github servers.

Description:

We use buildout for django development. During the buildout the django package is not
available. Because of this, django-sendfile won't install.

Explanation of the error.

setup.py contains this line:
version=import('sendfile').version

And import('sendfile') fires an import of django.http.

When django is not installed, django-sendfile can't be installed.
Easy fix:

Put the version in setup.py or put it in a file to be loaded by init.py and setup.py.

Traceback:

Running easy_install:
/usr/local/bin/python2.5 "-c" "from setuptools.command.easy_install import main; main()" "-mUNxd" "/home/roland/.buildout/eggs/tmp-8GqjX" "-q" "/home/roland/.buildout/downloads/dist/django-sendfile-0.2.0.tar.gz"
path=/home/roland/.buildout/eggs/setuptools-0.6c9-py2.5.egg

Traceback (most recent call last):
File "", line 1, in
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 1712, in main
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 1700, in with_ei_usage
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 1716, in
File "/usr/local/lib/python2.5/distutils/core.py", line 151, in setup
dist.run_commands()
File "/usr/local/lib/python2.5/distutils/dist.py", line 974, in run_commands
self.run_command(cmd)
File "/usr/local/lib/python2.5/distutils/dist.py", line 994, in run_command
cmd_obj.run()
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 211, in run
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 427, in easy_install
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 476, in install_item
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 655, in install_eggs
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 930, in build_and_install
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 919, in run_setup
File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 62, in run_setup
File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 105, in run
File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 64, in
File "setup.py", line 5, in
File "/tmp/easy_install-YsfOGK/django-sendfile-0.2.0/sendfile/init.py", line 7, in
ImportError: No module named django.http
An error occured when trying to install django-sendfile 0.2.0.Look above this message for any errors thatwere output by easy_install.

When installing django-sendfile through pip, I receive the following warning:

Downloading/unpacking django-sendfile==0.3.3 (from -r /.../requirements.txt (line 6))
  You are installing an externally hosted file. Future versions of pip will default to disallowing externally hosted files.
  You are installing a potentially insecure and unverifiable file. Future versions of pip will default to disallowing insecure files.

I believe this could be resolved by hosting the releases on PyPI instead of github.

Dear all,

I am wondering whether HTTP Byte Range requests are supported out-of-the-box?

I am trying to serve MP4 video files and realize that serving them from Django using sendfile (with backend "sendfile.backends.xsendfile") causes seeking to stop working in Chrome. If I serve the file locally through Apache, seeking works.

Thanks a lot for any pointers or tips, and a huge thank you for the great django-sendfile project!
Kaspar

I'm on my way of upgrading a project that uses django-sendfile to Django 1.9. Is Django 1.9 already supported? Thanks in advance

django_sendfile uses the same package namespace as http://code.google.com/p/pysendfile/. Maybe a better one would be "django_sendfile".

Hi,

I just released http://pypi.python.org/pypi/django-downloadview
then also just discovered django-sendfile.

I guess I would have used/contributed to django-sendfile if I discovered it before... Maybe it's not too late.

I haven't reviewed django-sendfile carefully yet, but the scope of the 2 applications seems very similar, with some differences in the implementation like:

• django-sendfile API is really simple, one function + backends
• django-download view focuses on class-based views, i.e. it is easy to use wherever django.views.generic.DetailView can be used.
• django-download view can use middlewares (global configuration) or decorators (per view configuration)

Maybe django-downloadview could use django-sendfile (i.e. provide class-based views which call the sendfile() function).
But maybe we could merge the two projects? Do you see blocker points?

Since django-sendfile seems to be older and certainly have more users, I guess it would be django-downloadview features merged into django-sendfile, i.e. deprecate django-downloadview.

When running Django 1.8, I get this warning (repeatedly):

py-env/local/lib/python2.7/site-packages/sendfile/__init__.py:23: RemovedInDjango19Warning: django.utils.importlib will be removed in Django 1.9.
  from django.utils.importlib import import_module

Suggested fix: just import importlib (and not django.utils.importlib), it's included in Python 2.7. Check https://docs.djangoproject.com/fr/1.8/releases/1.7/#deprecated-features-1-7, search for "importlib".

When using simple backend to serve a gzip file (for eg: test.gz), the file is decompressed on-the-fly and the content downloaded is uncompressed. I am not sure if I make mistake somewhere.

Somewhat related to #25, to make sure this maintains Python 3 compatibility, it'd be great to run the tests in Python 3 mode as well. I think this would be really easy to do for free with Travis CI, since the project has a pretty normal test suite.

Hello,

I want to apologize first if this will be simple problem, learning django and was trying your app. Was able to work out all of it except the last part.

I can load image or file to Django Admin and the url of the image is: download/6.jpg

when I click it will get an error:

http://cl.ly/image/0P420L0f3l1M

Even if I click in download list when files are public same error, probably I need to add that URL "protected/download" to urls.py but I would need to create a view then no?

Can you tell me the proper way to setup your example?

Thanks

There are some unresolved issues and pending pull requests with no answer.
Are you still maintaining this project ?

Please tell users that there is a maintained version: https://github.com/moggers87/django-sendfile2

Somehow google still shows your project first.

AFAIK pypi does not understand markdown syntax.

The page of django-sendfile looks strange:

https://pypi.python.org/pypi/django-sendfile

AFAIK there is online converter to convert markdown to restructured text.

Currently, if you try to use sendfile with a unicode attachment name, it results in an error.

I might be conflicting with django media settings but I have to append media to the path.

I added the following url:

    # protected media
    url(r'^media/(?P<path>.*)$', get_media, name='get_media')

Then the get_media function based view:

def get_media(request, path):
    # append media to path
    return sendfile(request, 'media/' + path)

If I don't append media. then it fails here:

if not os.path.exists(filename):
        from django.http import Http404
        raise Http404('"%s" does not exist' % filename)

Hi all,

Updating from 0.3.4 to 0.3.6, I had the bad surprise to see that it broke the support of files containing whitespaces.

The response of sendfile 0.3.4 for such a file was :
X-Accel-Redirect: /protected_files/1/files/Backup 2014-09-02-2.sqlbackup
Content-length: 70458
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="Backup 2014-09-02-2.sqlbackup.zip"

And now (since 0.3.5) it is:
X-Accel-Redirect: /protected_files/1/files/Backup%202014-09-02-2.sqlbackup
Content-length: 70458
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="Backup 2014-09-02-2.sqlbackup.zip"

Which makes the download fail...

Best,
Matthieu

On Django 1.7 and before, the Location header that is returned by the mod_wsgi backend is just the path to the file (eg: /media/documents/mydoc.pdf).

On Django 1.8, it has http:// appended to the beginning. So the above path has now changed to http:///media/documents/mydoc.pdf.

I'm asking my-self if I make one of my projects python 3.4/django 1.7 as I have big refactoring in front of me.

I used the nice tool https://caniusepython3.com/ and it told me that django-sendfile is not py3k compliant. When I read my self, it looks already compliant or trivial to port.

You probably should update your setup.py except if you haven't tried your project on py3k yet.

If you ran your tests against python 3, you probably should add this to your classifiers:

classifiers = [
"Programming Language :: Python :: 2",
"Programming Language :: Python :: 3",]

Since 0.3.6, sendfile has been URL escaping the file path before setting the X-Accel-Redirect header. This seems to confuse nginx, leading to it being unable to find a file with an @ in the name because it is looking for a file with a %40 in it.

As of version 0.3.2, sendfile() function takes a filename as input, and checks that this file exists using os.path.exists.
See

What about accepting file wrappers instead of filenames? such as FieldFile (file wrapper for FileField).
This would make it possible to serve files from various locations: local filesystem, storages, URL, in-memory files...

Apache 2.4 is not supported officially by mod_xsendfile, but it seems the EnableSendfile on configuration option that ships with my Apache 2.4 installation accomplishes the same thing. Switching to SENDFILE_BACKEND = 'sendfile.backends.xsendfile' improves performance with this setting on regardless of whether or not mod_xsendfile is installed on the machine. I may have gotten lucky with my configuration, but I think EnableSendfile on should be investigated as the long-term replacement for mod_xsendfile for this package.