Refactor HttpResponse.__iter__ / _get_content

[Aymeric Augustin]

The current implementation isn't DRY. It seems to me that _get_content should just return b''.join(self).

Unfortunately, implementing this naively results in test failures.

This code is sensitive, tricky, and lacks comment. A refactoring would be useful.

See also #4969, #16494, #18764, [5f2d9cdbb1], [2892cb0ec4], and [536b030363].

To sum up: this ticket is about cleaning up the conversion of HTTP response content to bytes.

[Aymeric Augustin]

When HttpResponse is instantiated with an iterator, the contents of the iterator should be consumed and saved as soon as response.content is accessed (or other methods requiring knowledge of the response's content).

We probably want to keep the current (undocumented) streaming behavior of HttpResponse and not unconditionally consume the iterator in __init__.

This was initially part of #7581 — but I'm reducing the scope of that ticket to something manageable.

EDIT: actually that's part of #6527; please ignore this comment.

[Aymeric Augustin]

This comment was made on #7581 but it actually falls in the scope of this ticket:

Returning self._iterator directly in HttpStreamingResponse.streaming_content, instead of a new iterator that yields bytestrings means that middleware authors can't expect consistent bytestring chunks when wrapping streaming_content in a new iterator? They may have to type check or coerce each chunk (potentially reproducing something like make_bytes()? For comparison, HttpResponse.content always returns a bytestring.

[Aymeric Augustin]

See also #16494 and #10190.

[Aymeric Augustin <aymeric.augustin@…>]

In da56e1bac6449daef9aeab8d076d2594d9fd5b44:

Fixed #18796 -- Refactored conversion to bytes in HttpResponse

Thanks mrmachine for the review.