#36293: Add test to verify non-blocking behavior of compress_sequence() with
zfile.flush()
-------------------------------+--------------------------------------
Reporter: huoyinghui | Owner: (none)
Type: New feature | Status: closed
Component: HTTP handling | Version: dev
Severity: Normal | Resolution: needsinfo
Keywords: gzip flush | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Changes (by Natalia Bidart):
* cc: Carlton Gibson, Matthew Somerville (added)
* component: Uncategorized => HTTP handling
* keywords: gzip blocking => gzip flush
* resolution: => needsinfo
* status: new => closed
* type: Uncategorized => New feature
* version: 5.2 => dev
Comment:
Hello huoyinghui, thank you for taking the time to create this ticket.
Initially your request made sense, but I did some archeology and in fact
`zfile.flush()` was removed in caa3562d5bec1196502352a715a539bdb0f73c2d
(while fixing #24242). I can see in your patch how you added a flag to
control whether the flushing occurs or not, but I'm not convinced this is
the right solution.
We would need some stronger evidence that the lack of flushing is causing
any issues with a streamed response. The commit above mentions:
> Testing shows without the flush() the buffer is being flushed every 17k
or so and compresses the same as if it had been done as a whole string.
I'll close as `needsinfo`, I'll add as cc a few folks, and edit the ticket
title to be more precise. Please reopen when you can provide more evidence
via a Django test project for proper assestment. Thank you!
--
Ticket URL: <
https://code.djangoproject.com/ticket/36293#comment:3>