Views return DownloadResponse.
Middlewares (and decorators) are given the opportunity to capture responses and convert them to ProxiedDownloadResponse.
Bases: django.http.response.StreamingHttpResponse
File download response (Django serves file, client downloads it).
This is a specialization of django.http.StreamingHttpResponse where streaming_content is a file wrapper.
Constructor differs a bit from HttpResponse:
Here are some highlights to understand internal mechanisms and motivations:
Let’s start by quoting PEP 3333 (WSGI specification):
For large files, or for specialized uses of HTTP streaming, applications will usually return an iterator (often a generator-iterator) that produces the output in a block-by-block fashion.
Django WSGI handler (application implementation) return response object.
django.http.HttpResponse and subclasses are iterators.
In StreamingHttpResponse, the __iter__() implementation proxies to streaming_content.
In DownloadResponse and subclasses, streaming_content is a file wrapper. File wrapper is itself an iterator over actual file content, and it also encapsulates access to file attributes (size, name, ...).
Return dictionary of automatically-computed headers.
Uses an internal _default_headers cache. Default values are computed if only cache hasn’t been set.
Return iterable of (header, value).
This method is called by http handlers just before WSGI’s start_response() is called... but it is not called by django.test.ClientHandler! :’(
Return basename.
Return a suitable “Content-Type” header for self.file.
Return mime-type of the file.
Return encoding of the file to serve.
Return the charset of the file to serve.
Bases: django.http.response.HttpResponse
Base class for internal redirect download responses.
This base class makes it possible to identify several types of specific responses such as XAccelRedirectResponse.