Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#13756 closed Bug (invalid)

File upload not working under Tomcat

Reported by: Sven Klemm Owned by: nobody
Component: HTTP handling Version: 1.2
Severity: Normal Keywords:
Cc: jeff250@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX:


Currently the file upload does not work under Django because the multipart parser assumes reading of data happens blocking and it always gets as much bytes as it specifies in read() which is not true under tomcat.

Attachments (1)

tomcat_fileupload.diff (562 bytes) - added by Sven Klemm 8 years ago.
Patch for multipart parser to make file upload work under tomcat

Download all attachments as: .zip

Change History (7)

Changed 8 years ago by Sven Klemm

Attachment: tomcat_fileupload.diff added

Patch for multipart parser to make file upload work under tomcat

comment:1 Changed 8 years ago by Carles Barrobés i Meix

I tested Sven's patch in Django 1.1.2 / Jython 2.5.1 / Tomcat 5.5. and it does solve the issue.

comment:2 Changed 8 years ago by Russell Keith-Magee

Triage Stage: UnreviewedAccepted

comment:3 Changed 7 years ago by Jeffrey Knockel

Cc: jeff250@… added

It looks like Jython/modjy in is calling ServletRequest.getInputStream() and thinly wrapping it with a Python file-like object before passing it to Django as environ['wsgi.input']. The problem is that has the semantics that, if given a length and if there are no exceptional conditions or EOF, then it will fill anywhere between 1 and length many bytes inclusive before unblocking and returning, whereas django is expecting it to block until exactly length many bytes are returned.

This explains why the patch works, but it's not clear to me if the bug is actually in Jython/modjy or in Django? Does WSGI require you to pass in a 'wsgi.input' file object that blocks on reads until a buffer of exactly the requested length is returned?

comment:4 Changed 7 years ago by Julien Phalip

Severity: Normal
Type: Bug

comment:5 Changed 7 years ago by Aymeric Augustin

Easy pickings: unset
Needs tests: set
Resolution: invalid
Status: newclosed

I'm following up on Jeff250's comment.

PEP 3333 says that wsgi.input is:

An input stream (file-like object) from which the HTTP request body bytes can be read. (The server or gateway may perform reads on-demand as requested by the application, or it may pre- read the client's request body and buffer it in-memory or on disk, or use any other technique for providing such an input stream, according to its preference.)

It adds that:

The semantics of each method are as documented in the Python Library Reference

In the Python Library Reference, the semantic of [file-like object].read() is:

Read at most size bytes from the file (less if the read hits EOF before obtaining size bytes).

This means that:

  • WSGI does require a wsgi.input file object that blocks on reads until a buffer of exactly the requested length is returned, or EOF / Content-Length is reached,
  • the bug is in modjy, which does not provide an appropriate file-like object right now.

comment:6 Changed 7 years ago by Jeffrey Knockel

I've opened a bug with the Jython folks for their input:

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