Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#32004 closed Cleanup/optimization (fixed)

Improve documentation of request.FILES

Reported by: Janos Roden Owned by: Janos Roden
Component: Documentation Version: 3.1
Severity: Normal Keywords: upload
Cc: Janos Roden Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Janos Roden)

Regarding request.FILES and multipart/form-data requests I think it worth to mention in the doc that the filename parameter of the content-disposition header of the part is ​crucial to handle the part as a file.

I used a low level library to generate requests and I thought Django will use a temporary file (and file name) for this content.
Of course after I found out how it works it's make sense, but read about it in the docs would have help me to fix my code much quicker.

Change History (11)

comment:1 by Janos Roden, 4 years ago

Cc: Janos Roden added

comment:2 by Janos Roden, 4 years ago

Description: modified (diff)

comment:3 by Carlton Gibson, 4 years ago

Triage Stage: Unreviewed β†’ Accepted

HI Janos, yes OK. Very happy to look at a suggestion to the docs here. Thanks.

comment:4 by Janos Roden, 4 years ago

Hi Carlton,

I'm thinking about ​this section:

Note that request.FILES will only contain data if the request method was POST and the <form> that posted the request has the attribute enctype="multipart/form-data". Otherwise, request.FILES will be empty.

Could be extended as

Note that request.FILES will only contain data from form fields if the request method was POST and the <form> that posted the request has the attribute enctype="multipart/form-data" and contains at least one <intput type="file"> field.
Or more technically if request method was POST, the Content-Type general header was multipart/form-data and the Content-Disposition subpart header contains the filename parameter (default behavior in browsers for this enctype).
Otherwise, request.FILES will be empty.

Feel free to correct my english, please.
I hope it isn't too complicated, what do you think?

comment:5 by Carlton Gibson, 4 years ago

Hi Janos. First glance seems a bit 😬: the point is the Content-Disposition header right? But how do we state that in the context of form submission... β€”Β yes, via the input... β€”Β Can you open a PR, and we discuss there? (It's much easier to review and suggest changes there.) Thanks.

comment:6 by Janos Roden, 4 years ago

Okay, I created one, let's discuss how to phrase it: ​https://github.com/django/django/pull/13425

comment:7 by Janos Roden, 4 years ago

Owner: changed from nobody to Janos Roden
Status: new β†’ assigned

comment:8 by Mariusz Felisiak, 4 years ago

Has patch: set

comment:9 by Carlton Gibson, 4 years ago

Triage Stage: Accepted β†’ Ready for checkin

comment:10 by Carlton Gibson <carlton@…>, 4 years ago

Resolution: β†’ fixed
Status: assigned β†’ closed

In 9e4b1ad:

Fixed #32004 -- Clarified docs for when request.FILES is set.

Co-authored-by: Carlton Gibson <carlton.gibson@…>

comment:11 by Carlton Gibson <carlton.gibson@…>, 4 years ago

In 1d7c4add:

[3.1.x] Fixed #32004 -- Clarified docs for when request.FILES is set.

Co-authored-by: Carlton Gibson <carlton.gibson@…>

Backport of 9e4b1ad33e436e8fe60af756d7e09639ee886ac2 from master

Note: See TracTickets for help on using tickets.
Back to Top