Bugzilla – Full Text Bug Listing
| Summary: | File Upload Problem with large files (> 1,5GB) | ||
|---|---|---|---|
| Product: | [RT] Jetty | Reporter: | Jose M. Alcaraz <jmalcaraz> |
| Component: | server | Assignee: | Greg Wilkins <gregw> |
| Status: | RESOLVED NOT_ECLIPSE | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | janb, jetty-inbox, stevel |
| Version: | unspecified | ||
| Target Milestone: | 7.0.2.RC0 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Jose M. Alcaraz
Jose, are you saying that IE, safari and Filezilla are sending a wrong content-length, or that Jetty is reading the content-length incorrectly? If an incorrect content-length is sent, then there is not much that Jetty can do. You will need to raise bugs on those browsers. (In reply to comment #1) > Jose, > are you saying that IE, safari and Filezilla are sending a wrong > content-length, > or that Jetty is reading the content-length incorrectly? > If an incorrect content-length is sent, then there is not much that Jetty can > do. You will need to raise bugs on those browsers. Hi Greg, thanks from you quick respose. Yes, I guess that the problem is ralated to a wrong content-lenght provided by the browsers or a bad interpretation of this value in the Jetty server. In fact, I guess that I have identified the exact class in which Jetty uses this value to manage the HTTP strem. It is the "HttpGenerator" class. If you like I can give you a servlet which processes a simple upload file and a jsp form which perform on the POST on the client side and you will discover that you will lost all the information in the client side because of the way in which the server manages the stream. P.S. Steve Loughran sends you grettings from HP Labs :) Thanks you very much for your time with this issue. Regards, Jose M. Alcaraz Automated Infrastructure Lab HP Labs Bristol Jose, If you have an example, please go ahead and attach to this issue. However, I'm still not clear on what you're saying? It is the browser that sets the content length isn't it? You can use tcpdump or wireshark to check that the content-length header is correct on the wire. thanks Jan If some browsers can generate >2GB files in forms which jetty handles (e.g. Chrome), and some don't, then it's the fault of the client for using signed integers for their content length. It sounds like IE does this, and so does the java.net HttpUrlConnection, though if you go to chunked everything works there. You can't ignore the content-length field and say "oh, they sent more, let's include the extra stuff", as that could be a sign of trouble all of its own. Same for clients, any mismatch between what was promised and what was delivered is trouble and should be acted on, not ignored. I'm testing this at the moment against jetty 7.1 (trunk). There was a problem fixed in 7.1.1 about converting large content lengths into a long, but I don't see how that could directly effect file uploads... although that depends on the exact handling. Are you using the jetty multipart filter? attaching your example would be good. Also if you could capture the headers of any POST requests sent from a good browser and a bad browser, that would be very very helpful! Use tcpdump or wireshark for that. cheers Wow multipart filter is slow! But I've had no problem with a 1.9Gb file from FF and jetty 7.1. I'll test a 2.1Gb next (as that will overflow a signed int). cheers hmm firefox refuses to send a file bigger than 2GB. So IE is close to the limit anyway. I would really like to see the wireshark captures from IE. I don't have a virtual machine big enough to play with 2GB files and IE. I'm closing this unless there is some indication that it is jetty that is in the wrong. A wireshark dump of the correct headers being handled wrongly would be good to show this. cheers |