[
https://issues.apache.org/jira/browse/FILEUPLOAD-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14221406#comment-14221406
]
Bernd Eckenfels commented on FILEUPLOAD-262:
--------------------------------------------
Looks like the "null" is a red herring, and this is actually an aborted upload
or a null-byte body?
> Processing of multipart/form-data request failed. null
> ------------------------------------------------------
>
> Key: FILEUPLOAD-262
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-262
> Project: Commons FileUpload
> Issue Type: Bug
> Affects Versions: 1.2, 1.3.1
> Environment: Application: Jetty 9.1.4, Debian stable x86_64, Java
> 1.7.0_51
> Public access through reverse proxy (apache 2 2.2.22 + mod_proxy)
> Reporter: Kristian Rink
> Priority: Minor
> Labels: eof, exception, stacktrace
>
> Exposing an upload feature in an existing web application, I frequently see
> stack traces as the one posted below in my server log files. Additional notes:
> - The application runs in an embedded jetty (HTTP) behind an apache2
> mod_proxy reverse proxy (HTTPS).
> - These issues do not generally appear, I tried quite some uploading
> myself today and never managed to reproduce this behaviour even while
> uploading loads of files, large files and both together.
> - It does not seem to be generally tied to a particular browser; the
> users associated with these messages use Firefox, MSIE or Chrome.
> - Looking at network traffic (and the transfer monitor in the app), it
> _seems_ all data to be sent with the request have successfully been
> transmitted yet parsing the request, ultimately, fails.
> - On _some_ clients, in such situations users reported the upload was
> canceled with a "connection reset by peer" error, even though I do not
> see reasons for that in our mod_proxy server log.
> - The application uses the approach outlined in [1] to render a progress bar
> based upon JavaScript and DWR. There is code in that controller trying to
> check how much data has been received by the server so far. I do dump these
> information to the log right now, and it seems all(?) data has been received
> before we run into this error, even though I am not sure about that at all as
> I am unsure how the frameworks handles HTTP traffic internally and how this
> is handled in example with chunked transfer encoding:
> 2014-11-21 18:26:01,846 [qtp1780643722-438] INFO WebUIUploadController -
> uploadStats: 2100399 of 2100399
> Stack trace seen in such situations:
> {code:java}
> org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
> Processing of multipart/form-data request failed. null
> at
> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:351)
> ~[commons-fileupload-1.3.1.jar:1.3.1]
> at
> org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:115)
> ~[commons-fileupload-1.3.1.jar:1.3.1]
> at
> de.pc.frontend.WebUIUploadController.submitUpload(WebUIUploadController.java:189)
> ~[webprojekt-1.2-SNAPSHOT.jar:na]
> at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source)
> ~[na:na]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.7.0_51]
> at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_51]
> at
> org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:176)
> [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:436)
> [spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:424)
> [spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:790)
> [spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719)
> [spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:669)
> [spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:585)
> [spring-webmvc-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> [javax.servlet-api-3.1.0.jar:3.1.0]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> [javax.servlet-api-3.1.0.jar:3.1.0]
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:738)
> [jetty-servlet-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1651)
> [jetty-servlet-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83)
> [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
> [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1639)
> [jetty-servlet-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
> [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
> [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1631)
> [jetty-servlet-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:549)
> [jetty-servlet-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> [jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:568)
> [jetty-security-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
> [jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1111)
> [jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:478)
> [jetty-servlet-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)
> [jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1045)
> [jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> [jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> [jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
> at org.eclipse.jetty.server.Server.handle(Server.java:462)
> [jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:279)
> [jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:232)
> [jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:534)
> [jetty-io-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607)
> [jetty-util-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536)
> [jetty-util-9.1.4.v20140401.jar:9.1.4.v20140401]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> Caused by: org.eclipse.jetty.io.EofException: null
> at org.eclipse.jetty.server.HttpInput$3.noContent(HttpInput.java:465)
> ~[jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
> at org.eclipse.jetty.server.HttpInput.read(HttpInput.java:125)
> ~[jetty-server-9.1.4.v20140401.jar:9.1.4.v20140401]
> at
> org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:999)
> ~[commons-fileupload-1.3.1.jar:1.3.1]
> at
> org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:903)
> ~[commons-fileupload-1.3.1.jar:1.3.1]
> at java.io.InputStream.read(InputStream.java:101) ~[na:1.7.0_51]
> at org.apache.commons.fileupload.util.Streams.copy(Streams.java:100)
> ~[commons-fileupload-1.3.1.jar:1.3.1]
> at org.apache.commons.fileupload.util.Streams.copy(Streams.java:70)
> ~[commons-fileupload-1.3.1.jar:1.3.1]
> at
> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:347)
> ~[commons-fileupload-1.3.1.jar:1.3.1]
> ... 39 common frames omitted
> {code}
> There is Spring in there but the problem seems unrelated. It happens just
> alike using fileupload 1.2 and 1.3.1. I have seen similar issues before using
> the same application in Sun/Oracle Glassfish, too. Playing with the
> configuration of the reverse proxy in front (especially talking keepalive,
> chunked vs. non-chunked transfers, timeouts, ...) doesn't seem to change
> much.
> Seen this pretty often so far, yet have no reliable way of reproducing it.
> Feel free to ask for more information, not sure how useful this is so far.
> [1]http://jtechnoprojects.blogspot.de/p/ajax-file-upload-with-progress-bar.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
