#30694 closed Bug (fixed)
Document FileResponse does not seek its file source
Reported by: | Claude Paroz | Owned by: | nobody |
---|---|---|---|
Component: | Documentation | Version: | 2.2 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I'm not sure this is a bug, but I was bitten by some code today:
buffer = io.BytesIO() buffer.write(b'some binary content') return FileResponse(buffer, filename='somename.bin')
and the response is empty because the stream position is at the end of the buffer. I can easily fix that by seeking the buffer myself, but shouldn't FileResponse
seek itself in _set_streaming_content
before calling filelike.read
?
Change History (6)
comment:1 by , 5 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 5 years ago
Component: | HTTP handling → Documentation |
---|---|
Summary: | FileResponse does not seek its file source → Document FileResponse does not seek its file source |
Something like that?:
diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt index 19593dfb90..3dfbf28cf6 100644 --- a/docs/ref/request-response.txt +++ b/docs/ref/request-response.txt @@ -1122,6 +1122,8 @@ Attributes If ``open_file`` doesn't have a name or if the name of ``open_file`` isn't appropriate, provide a custom file name using the ``filename`` parameter. + Note that if you pass a file-like object like ``io.BytesIO``, it's your + task to ``seek()`` it before passing it to ``FileResponse``. The ``Content-Length`` and ``Content-Type`` headers are automatically set when they can be guessed from contents of ``open_file``.
I suspect the example in https://docs.djangoproject.com/en/2.2/howto/outputting-pdf/#write-your-view is missing the seek call.
comment:3 by , 5 years ago
Resolution: | wontfix |
---|---|
Status: | closed → new |
Triage Stage: | Unreviewed → Accepted |
Yep, I'll take that. Perfect. 🙂
Note:
See TracTickets
for help on using tickets.
Hi Claude.
I think not here.
I imagine a situation where you want to tail a log, say. You can't do that if we reset the stream position ourselves.
I then think that resetting the stream makes
FileResponse
a little bit too clever. (Happy if someone wants to put that in a subclass, but it's beyond "take a buffer, stream it to an HTTP response", which is what I take to be the limit of the scope here.)So, for me, the maxim in play is, "You pass an open file. Your responsibility to
seek
accordingly".As such, I'm going to go with
wontfix
. I hope that makes sense.Maybe an addition to the FileResponse docs?
(Or such, somewhere.)