flush() after writing to gzip_file

[vin]

Summary

In order to better support streaming responses where the chunks are smaller than the file buffer size, we flush after writing.

Without the explicit flush, the writes are buffered and the subsequent reads see an empty self.gzip_buffer until the file automatically flushes due to either (1) the 32KiB write buffer¹ fills or (2) the file is closed because the streaming response is complete.

Without flushing, the GZipMiddleware doesn't work as expected for streaming responses, especially not for Server-Sent Events which are expected to be delivered immediately to clients. The code as written appears to intend to flush immediately rather than buffering, as it does immediately call await self.send(message), but in practice that message is often empty.

Checklist

• I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.

Footnotes

1. https://github.com/python/cpython/blob/main/Lib/gzip.py#L26 ↩

[Kludex]

Can we add a test to prove your point?

[vin]

I'll work on that today. I have a small repro case I'll share but I need to make it run as a test

[vin]

I've added a test, but it's a bit complicated. Without the flush, the entire contents of the response are correct, but to show that they are received iteratively rather than all at once, I use a wrapping middleware to assert that GZipMiddleware isn't sending empty message bodies, which is what it does without the flush.

[vin]

@Kludex could you take another look or recommend a good reviewer? Thanks!

[josecsotomorales]

I'm honestly not sure if this is related, but I have a FastAPI project and I'm getting some GZIP exceptions after upgrading to Python 3.13

Exception ignored in: <gzip on 0x7f42bf6a0130>
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/gzip.py", line 359, in close
    fileobj.write(self.compress.flush())
ValueError: I/O operation on closed file.
Exception ignored in: <gzip on 0x7f42bf6a2dd0>
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/gzip.py", line 359, in close
    fileobj.write(self.compress.flush())
ValueError: I/O operation on closed file.
Exception ignored in: <gzip on 0x7f42b40bb460>
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/gzip.py", line 359, in close
    fileobj.write(self.compress.flush())
ValueError: I/O operation on closed file.
Exception ignored in: <gzip on 0x7f42be191de0>
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/gzip.py", line 359, in close
    fileobj.write(self.compress.flush())
ValueError: I/O operation on closed file.
Exception ignored in: <gzip on 0x7fd2c45fd450>
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/gzip.py", line 359, in close
    fileobj.write(self.compress.flush())
ValueError: I/O operation on closed file.
2024-12-04 00:30:04.105 | INFO     | logging:callHandlers:1736 - 127.0.0.1:59939 - "GET /api/ HTTP/1.1" 200

I have the following GZIP wrapper:

import gzip
from typing import Callable

from fastapi import Request, Response
from fastapi.routing import APIRoute


class GzipRequest(Request):
    async def body(self) -> bytes:
        if not hasattr(self, "_body"):
            body = await super().body()
            if "gzip" in self.headers.getlist("Content-Encoding"):
                body = gzip.decompress(body)
            self._body = body  # noqa
        return self._body


class GzipRoute(APIRoute):
    def get_route_handler(self) -> Callable:
        original_route_handler = super().get_route_handler()

        async def custom_route_handler(request: Request) -> Response:
            request = GzipRequest(request.scope, request.receive)
            return await original_route_handler(request)

        return custom_route_handler

[Kludex]

Not related.

[vin]

Any concerns here, or how can we best move this forward?

[Kludex]

Any concerns here, or how can we best move this forward?

The best way to move forward would be to present the problem first, with an MRE, and references to other issues where other people had the same problem.

I think the current behavior is intentional, so I need to get more references around before reviewing this.

[vin]

Best observed in a browser, but here's a small repro:

import time
from fastapi import FastAPI
from fastapi.middleware.gzip import GZipMiddleware
from fastapi.responses import StreamingResponse

app = FastAPI()
app.add_middleware(GZipMiddleware)

@app.get("/")
def streaming_response():

    def generate():
        for i in range(10):
            yield f'event: ping\ndata: {{"i": {i}}}\n\n'
            time.sleep(1)
    return StreamingResponse(
        generate(),
        media_type="text/event-stream"
    )

and what it looks like before this PR:

and after:

In the first case, all responses appear together after 10 seconds. In the second, every 1 second a new event appears.

[vin]

If the behavior is intentional, we really need to update the documentation here:
https://fastapi.tiangolo.com/advanced/middleware/#gzipmiddleware

The middleware will handle both standard and streaming responses.

to indicate that this will cause streaming responses to be buffered 32KiB at a time; this was certainly a surprising result for us, and one that caused our users to report that our app appeared broken as realtime status updates stopped working.