Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#13756 closed Bug (invalid)

File upload not working under Tomcat

Reported by: SvenKlemm 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:

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

Download all attachments as: .zip

Change History (7)

Changed 5 years ago by SvenKlemm

Patch for multipart parser to make file upload work under tomcat

comment:1 Changed 5 years ago by txels

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 5 years ago by russellm

  • Triage Stage changed from Unreviewed to Accepted

comment:3 Changed 5 years ago by Jeff250

  • 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 Changed 4 years ago by julien

  • Severity set to Normal
  • Type set to Bug

comment:5 Changed 4 years ago by aaugustin

  • Easy pickings unset
  • Needs tests set
  • Resolution set to invalid
  • Status changed from new to closed

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 4 years ago by Jeff250

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