Opened 14 years ago

Closed 13 years ago

Last modified 13 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: no

Description

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 14 years ago.
Patch for multipart parser to make file upload work under tomcat

Download all attachments as: .zip

Change History (7)

by Sven Klemm, 14 years ago

Attachment: tomcat_fileupload.diff added

Patch for multipart parser to make file upload work under tomcat

comment:1 by Carles Barrobés i Meix, 14 years ago

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 by Russell Keith-Magee, 14 years ago

Triage Stage: UnreviewedAccepted

comment:3 by Jeffrey Knockel, 14 years ago

Cc: jeff250@… added

It looks like Jython/modjy in modjy_wsgi.py 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 InputStream.read(...) 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 by Julien Phalip, 14 years ago

Severity: Normal
Type: Bug

comment:5 by Aymeric Augustin, 13 years ago

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 by Jeffrey Knockel, 13 years ago

I've opened a bug with the Jython folks for their input:
http://bugs.jython.org/issue1754

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