#16470 closed New feature (fixed)
Make FileResponse set the Content-Disposition header
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | HTTP handling | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | jdunck@…, jreschke | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
RFC6266, recently published by the IETF HTTPbis WG, describes a way to use the Content-Disposition header in HTTP in a manner whereby almost all current browsers can handle files (e.g., downloading with disposition 'attachment') that have non-ASCII characters in them, with other browsers using an ASCII fallback.
Django currently does not have an API for setting Content-Disposition, although there are a few references to it in the documentation. Adding such an API would allow Django sites to download files in any language easily.
Additionally, there's advice in the RFC that, properly implemented in a Django API, would help sites avoid common pitfalls.
For more information, see:
http://trac.tools.ietf.org/wg/httpbis/trac/wiki/ContentDispositionProducerAdvice
Change History (13)
comment:1 by , 13 years ago
Cc: | added |
---|
comment:2 by , 13 years ago
Component: | Internationalization → HTTP handling |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:3 by , 13 years ago
Mark had discussed this with me over twitter/email a couple days ago. He's got an example implementation here: https://github.com/mnot/sweet/blob/master/lib/index.js
I was thinking of trying to keep the existing API of dict key/value as header/value pair, but having __setitem__
do some special-casing on Content-Disposition. This would allow do something sensible for all existing code, and we could still add an extra method if people wanted finder control over the fallback filename.
comment:4 by , 13 years ago
This seems to be special case of the encoding in http://tools.ietf.org/html/rfc5987
Seems to me that whatever solution we come up with should generalize to any header that allows RFC 5987-style encodings.
comment:5 by , 9 years ago
Summary: | RFC6266 Support → RFC5987/RFC6266 Support (Content-Disposition headers) |
---|
comment:6 by , 7 years ago
Now that we have a FileResponse subclass, what about adding a parameter to this subclass which would then set the Content-Disposition
header appropriately? Would that satisfy most use cases?
The PDF output example could be then rewritten as:
import io from reportlab.pdfgen import canvas from django.http import FileResponse def some_view(request): # Create a file-like buffer to receive PDF data buffer = io.BytesIO() # Create the PDF object, using the buffer as its "file." p = canvas.Canvas(buffer) # Draw things on the PDF. Here's where the PDF generation happens. # See the ReportLab documentation for the full list of functionality. p.drawString(100, 100, "Hello world.") # Close the PDF object cleanly, and we're done. p.showPage() p.save() return FileResponse(buffer, as_attachment=True, filename="somefilename.pdf")
comment:10 by , 7 years ago
Summary: | RFC5987/RFC6266 Support (Content-Disposition headers) → Make FileResponse set the Content-Disposition header |
---|---|
Triage Stage: | Accepted → Ready for checkin |
This is a very common problem for developers, and I think it's in the realm of what Django should do. I guess it means adding a method to
HttpResponse
.If the implementation isn't completely obvious, please start a discussion to django-developers to ensure consensus.