summaryrefslogtreecommitdiff
path: root/tests/httpwrappers
diff options
context:
space:
mode:
authorMatthew Somerville <matthew-github@dracos.co.uk>2015-01-28 21:43:23 +0000
committerClaude Paroz <claude@2xlibre.net>2015-02-03 18:19:06 +0100
commitd88c24f436ae23ff5aec4ea06c0c27499a71e074 (patch)
tree75025815afd5f392ba93b8c9a91b99fdf5e1c944 /tests/httpwrappers
parent43b0131fb5724cb92716eedfe35a6b2b4d84e1e5 (diff)
[1.8.x] Fixed #24240 -- Allowed GZipping a Unicode StreamingHttpResponse
make_bytes() assumed that if the Content-Encoding header is set, then everything had already been dealt with bytes-wise, but in a streaming situation this was not necessarily the case. make_bytes() is only called when necessary when working with a StreamingHttpResponse iterable, but by that point the middleware has added the Content-Encoding header and thus make_bytes() tried to call bytes(value) (and dies). If it had been a normal HttpResponse, make_bytes() would have been called when the content was set, well before the middleware set the Content-Encoding header. This commit removes the special casing when Content-Encoding is set, allowing unicode strings to be encoded during the iteration before they are e.g. gzipped. This behaviour was added a long time ago for #4969 and it doesn't appear to be necessary any more, as everything is correctly made into bytes at the appropriate places. Two new tests, to show that supplying non-ASCII characters to a StreamingHttpResponse works fine normally, and when passed through the GZip middleware (the latter dies without the change to make_bytes()). Removes the test with a nonsense Content-Encoding and Unicode input - if this were to happen, it can still be encoded as bytes fine. Backport of 250aa7c39b from master.
Diffstat (limited to 'tests/httpwrappers')
-rw-r--r--tests/httpwrappers/tests.py16
1 files changed, 8 insertions, 8 deletions
diff --git a/tests/httpwrappers/tests.py b/tests/httpwrappers/tests.py
index cc324b76cd..14ad306c65 100644
--- a/tests/httpwrappers/tests.py
+++ b/tests/httpwrappers/tests.py
@@ -348,14 +348,6 @@ class HttpResponseTests(unittest.TestCase):
#'\xde\x9e' == unichr(1950).encode('utf-8')
self.assertEqual(r.content, b'123\xde\x9e')
- # with Content-Encoding header
- r = HttpResponse()
- r['Content-Encoding'] = 'winning'
- r.content = [b'abc', b'def']
- self.assertEqual(r.content, b'abcdef')
- self.assertRaises(TypeError if six.PY3 else UnicodeEncodeError,
- setattr, r, 'content', ['\u079e'])
-
# .content can safely be accessed multiple times.
r = HttpResponse(iter(['hello', 'world']))
self.assertEqual(r.content, r.content)
@@ -512,6 +504,14 @@ class StreamingHttpResponseTests(TestCase):
self.assertEqual(list(r), [b'abc', b'def'])
self.assertEqual(list(r), [])
+ # iterating over Unicode strings still yields bytestring chunks.
+ r.streaming_content = iter(['hello', 'café'])
+ chunks = list(r)
+ # '\xc3\xa9' == unichr(233).encode('utf-8')
+ self.assertEqual(chunks, [b'hello', b'caf\xc3\xa9'])
+ for chunk in chunks:
+ self.assertIsInstance(chunk, six.binary_type)
+
# streaming responses don't have a `content` attribute.
self.assertFalse(hasattr(r, 'content'))