1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
=========
Questions
=========
- What about the `BREACH attack`_?
Django provides mitigations against the BREACH attack since version 1.10. For
additional protection, you can consider ``django-debreach`` and rate limiting.
If you are using the builtin CSRF mechanisms (i.e. not roling your own), you
are probably safe as far as BREACH is concerned.
.. _BREACH attack: http://breachattack.com/
- Why not implement each possible encoding as its own middleware and apply them
in order?
While this is a clean design, it suffers from a few shortcomings. It requires
developers / system administrators to add multiple middlewares for a single
concern, and it might duplicate some functionality, such as parsing the
``Accept-Encoding`` header.
- Why not let the web server handle the compression?
It is a good idea to let the web server handle the compression, as it might be
more optimised for it, and it frees up your application resources for handling
the application. This middleware is appropriate for cases where the webserver
is not able to do it or does not support the latest compression algorithms.
Moreover, compression in middleware unlocks the possibility of caching
compressed pages which might be beneficial in some cases.
- What about streaming responses?
Just like ``GZipMiddleware``, streaming responses are supported, and the
compressed data is streamed as it becomes available from the compressor.
- What about compression with the deflate algorithm?
The deflate algorithm provides very little benefit over gzip in terms of
compression — it is actually the same algorithm, but using 11 bytes less
overhead. Due to historical incompatibilities most people prefer gzip over
deflate. There is no realistic chance today of a client supporting deflate
that doesn't also support gzip.
- What about compression with the SDCH algorithm? (Or bzip2, lma, xz...)
These are not in IANA's `content coding registry`_ and are not widely
supported by clients. Zstandard is supported, though.
.. _content coding registry: https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding
- Does this provide any real value over Django's ``GZipMiddleware``?
Brotli promises better compression using less CPU time, and fast
decompression. It is now widely supported in browsers. For small responses
the effects of any compression algorithm is likely to be small. For a small
web response of a few KB Brotli is unlikely to need less MTUs than gzip. It
should use slightly less CPU time for compression and decompression than
gzip, but the difference will be small. In terms of total time in the
request-response cycle over the internet, you are unlikely to save more than
a millisecond. For larger responses, the effects become more pronounced, and
you might benefit in the order of multiple milliseconds compared to gzip.
Naturally this all depends heavily on the content of the response, the server
and client CPUs and the attributes of the network connection.
Django compression middleware tries to choose parameters so that using Brotli
should usually use less CPU time and result in a smaller response than with
gzip. If you specifically target very slow or very fast connections, a slight
tweak to the compression level might provide a slightly better balance of
priorities.
- Isn't compression of small responses a waste of time?
It could well be. Django compression middleware addresses this in two ways:
- We check if the response after compression is smaller by some margin. If it
isn't, the uncompressed response is sent.
- If the response is very small before compression, it is sent uncompressed.
All of this means that users and system administrators should benefit
regardless of whether they are on fast or slow connections or computers. The
benefit in any specific case might be small, but you should benefit in
aggregate spread over all your responses.
|
