Incompatibel breaking changes to getParameter() / getPart() probably for Ticket GLASSFISH-16740

[glassfishrobot]

The attached servlet shows a problem when calling HttpServletRequest.getParameter(name) before response.getWriter()/getInputStream().

In glassfish 3.1 this used to work and print out the form data (the content of the InputStream could still be used after calling getParameter()). This has changed in glassfish 3.1.2 probably because of the changes for #16740.

These changes will cause major problems in web applications that use multipart formdata, but do not yet use the getParts() method to retrieve the data, but some proprietary method. Any call to getParameter() before the files are parsed will cause the parsing of the multipart formdata to fail. I'm currently experiencing this with the Magnolia CMS (http://www.magnolia-cms.com/) where every single form stopped working in glassfish 3.1.2 with the following exception:

java.io.IOException: Corrupt form data: premature ending at com.oreilly.servlet.multipart.MultipartParser.(MultipartParser.java:205) at com.oreilly.servlet.MultipartRequest.(MultipartRequest.java:222) at info.magnolia.cms.filters.CosMultipartRequestFilter.parseParameters(CosMultipartRequestFilter.java:101) at info.magnolia.cms.filters.CosMultipartRequestFilter.doFilter(CosMultipartRequestFilter.java:81) at info.magnolia.cms.filters.OncePerRequestAbstractMgnlFilter.doFilter(OncePerRequestAbstractMgnlFilter.java:60) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.ContentTypeFilter.doFilter(ContentTypeFilter.java:104) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:88) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.ContextFilter.doFilter(ContextFilter.java:120) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:88) at info.magnolia.cms.filters.MgnlFilterChain.doFilter(MgnlFilterChain.java:82) at info.magnolia.cms.filters.CompositeFilter.doFilter(CompositeFilter.java:66) at info.magnolia.cms.filters.AbstractMgnlFilter.doFilter(AbstractMgnlFilter.java:88) at info.magnolia.cms.filters.MgnlMainFilter.doFilter(MgnlMainFilter.java:105) at info.magnolia.cms.filters.MgnlMainFilter.doFilter(MgnlMainFilter.java:216) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662)

I think a better way to do this is to only parse the multipart formdata for Servlets that have an javax.servlet.annotation.MultipartConfig annotation. The JavaDocs for this class state: "the Servlets annotated with MultipartConfig may retrieve the Part components of a given multipart/form-data request by calling getPart or getParts." So servlets without this annotation should not expect the getParts() method to work anyway.

Environment

Linux version 2.6.32-38-generic

Affected Versions

[3.1.2_dev]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/18444
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @yaminikb
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented hedes1 said: Same issue with richfaces when using rich:fileupload and apache common file upload. We could not use the 3.1.2 version in production until this issue is solved. Regards

[glassfishrobot]

@glassfishrobot Commented james.falkner said: Liferay Portal is also running into the exact same issue. See http://issues.liferay.com/browse/LPS-25521

We are completely broken on GlassFish 3.1.2 until this is fixed (or we work around it). Liferay code is not prepared to handle getPart()/getParts() and I'd suggest that GlassFish respect the annotations described above.

[glassfishrobot]

@glassfishrobot Commented kwutzke said: Also running into this with RichFaces 4 fileUpload. Cannot use my current webapp on that server. Need to fall back to GF 3.1.1 until this is fixed.

EDIT: downloading http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/promoted/glassfish-3.1.2-b14.zip works around this issue. The assumption of relating to #16740 appears to be correct.

[glassfishrobot]

@glassfishrobot Commented kchung said: A possible fix. Drop it into /modules directory, replacing the one with the same name there.

[glassfishrobot]

@glassfishrobot Commented kchung said: When getParmeter() is called for multipart form data, the servlet 3.0 spec is vague on whether the container should process the multipart stuff when the servlet is not annotated with @MultipartConfig. After consulting with the servlet spec leads, we agree that web container would not process any mutipart data unless the multipart is configured either with an annotation or web.xml. The spec would be rewritten to clarify this.

Fixed in the trunk workspace.

For those who runs on 3.1.2, I've attach a jar. Just drop it into /modules directory, replacing the one there. Please try it out and let me know if that fixes the problem.

[glassfishrobot]

@glassfishrobot Commented james.falkner said: Confirmed that the fix works for Liferay! Thanks a bunch for the fix on trunk and the patched binary kchung!

[glassfishrobot]

@glassfishrobot Commented kwutzke said: I can also confirm that the fix works (rich:fileUpload problem).

[glassfishrobot]

@glassfishrobot Commented sohildarshan said: Thanks. The Patch Works.

[glassfishrobot]

@glassfishrobot Commented kchung said: The fix for glassfish 3.1.2 is as the following. Note that this is not the same as the fix on the trunk, due to the differences between the two sources.

Index: src/main/java/org/apache/catalina/core/StandardWrapper.java

— src/main/java/org/apache/catalina/core/StandardWrapper.java (revision 52833)+++ src/main/java/org/apache/catalina/core/StandardWrapper.java (working copy) @@ -314,6 +314,7 @@ /**

• File upload (multipart) support */

  • private boolean multipartConfigured = false; private String multipartLocation = null; private long multipartMaxFileSize = -1L; private long multipartMaxRequestSize = -1L; @@ -768,11 +769,15 @@ return allow.toArray(methodNames); }

• public boolean isMultipartConfigured()

{ + return multipartConfigured; + }

/**

• Sets the multipart location */ public void setMultipartLocation(String location) { + multipartConfigured = true; multipartLocation = location; }

@@ -789,6 +794,7 @@

• Sets the multipart max-file-size */ public void setMultipartMaxFileSize(long maxFileSize) { + multipartConfigured = true; multipartMaxFileSize = maxFileSize; }

@@ -805,6 +811,7 @@

• Sets the multipart max-request-size */ public void setMultipartMaxRequestSize(long maxRequestSize) { + multipartConfigured = true; multipartMaxRequestSize = maxRequestSize; }

@@ -821,6 +828,7 @@

• Sets the multipart file-size-threshold */ public void setMultipartFileSizeThreshold(int fileSizeThreshold) { + multipartConfigured = true; multipartFileSizeThreshold = fileSizeThreshold; }

Index: src/main/java/org/apache/catalina/connector/Request.java

— src/main/java/org/apache/catalina/connector/Request.java (revision 52833)+++ src/main/java/org/apache/catalina/connector/Request.java (working copy) @@ -1,7 +1,7 @@ /*

• DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER. *

• • Copyright (c) 1997-2011 Oracle and/or its affiliates. All rights reserved.
  • • Copyright (c) 1997-2012 Oracle and/or its affiliates. All rights reserved.

• The contents of this file are subject to the terms of either the GNU

• General Public License Version 2 only ("GPL") or the Common Development @@ -78,6 +78,7 @@ import org.apache.catalina.core.ApplicationHttpResponse; import org.apache.catalina.core.StandardContext; import org.apache.catalina.core.StandardHost; +import org.apache.catalina.core.StandardWrapper; import org.apache.catalina.deploy.LoginConfig; import org.apache.catalina.fileupload.Multipart; import org.apache.catalina.security.SecurityUtil; @@ -3147,7 +3148,8 @@ } else { contentType = contentType.trim(); }

• if ("multipart/form-data".equals(contentType)) {

  • if (isMultipartConfigured() &&
  • "multipart/form-data".equals(contentType)) { getMultipart().init(); }

  if (!("application/x-www-form-urlencoded".equals(contentType)))

  { @@ -4063,13 +4065,29 @@ return multipart; }

• private boolean isMultipartConfigured() {

• if (wrapper instanceof StandardWrapper)

{ + return ((StandardWrapper)wrapper).isMultipartConfigured(); + }

• return false;
• }
• private void checkMultipartConfiguration(String name) {
• if (! isMultipartConfigured())

{ + throw new IllegalStateException( + sm.getString("coyoteRequest.multipart.not.configured", name)); + }

• }

• @Override public Collection getParts() throws IOException, ServletException

{ + checkMultipartConfiguration("getParts"); return getMultipart().getParts(); }

@Override public Part getPart(String name) throws IOException, ServletException

{ + checkMultipartConfiguration("getPart"); return getMultipart().getPart(name); }

Index: src/main/resources/org/apache/catalina/connector/LocalStrings.properties

— src/main/resources/org/apache/catalina/connector/LocalStrings.properties (revision 52833) +++ src/main/resources/org/apache/catalina/connector/LocalStrings.properties (working copy) @@ -103,6 +103,7 @@ coyoteRequest.nullRemoteAddressFromProxy=PWC4013: Unable to determine client remote address from proxy (returns null) object.invalidScope=PWC4014: Cannot use this object outside a servlet's service method or outside a filter's doFilter method inputBuffer.streamClosed=PWC4015: Stream closed +coyoteRequest.multipart.not.configured=PWC4016: Request.

{0}

is called without multipart configuration. Either add a @MultipartConfig to the servlet, or a multipart-config element to web.xml

#

1. Messages related to async processing mode

[glassfishrobot]

@glassfishrobot Commented kchung said: BugDB 13899761 created for 3.1.2.1 release.

[glassfishrobot]

@glassfishrobot Commented robweaver said: Just updated to 3.1.2 (Build 23) and the FileUpload on PrimeFaces broke (I think due to this issue).

Upload widget acts as if the upload is working, but never hits the back end event handler.

Reverting to 3.1 with no changes to WAR and the file upload works again.

Would be glad to help diagnose this issue.

Using the b14 build mentioned above also appears to resolve this issue.

Any target date for the fix, and is there a workaround ?

[glassfishrobot]

@glassfishrobot Commented kchung said: robweaver, have you tried the patch?

[glassfishrobot]

@glassfishrobot Commented robweaver said: Downloading http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/promoted/glassfish-3.1.2-b14.zip works around this issue.

Is there another patch you'd like me to try, or something you'd like me to trace ?

[glassfishrobot]

@glassfishrobot Commented kchung said: No, I was referring to the web-core.jar file that I've attached to this bug, and which worked for others.

[glassfishrobot]

@glassfishrobot Commented robweaver said: Confirmed - the web-core.jar does seem to correct the issue.

[glassfishrobot]

@glassfishrobot Commented tmpsa said: I second the confirmation - I too had broken file upload after upgrading to 3.1.2, and the patched web-core.jar solved the problem. Many thanks!

May I suggest that you add downloads of this kind of critical patches to the GF 3.1.2 download page? That would probably make a lot of users very happy.

[glassfishrobot]

@glassfishrobot Commented fh_dumay said: I had the same issue with artifactory - and replacing the web-core.jar in glassfish solved the problem

[glassfishrobot]

@glassfishrobot Commented haseebtahir said: I have same problem, but after even replacing web-core.jar in GF-dir/modules, my problem didn't get resolved. application running into glassfish 3.1.2 (build 23) and application built on JSF 2.2, Richfaces 4.3.2, Spring 3.0 and hibernate.

Please help me in this regard.

[glassfishrobot]

@glassfishrobot Commented kchung said: Can you give me a small test case? Did you have the same problem with 4.0? The fix should be already in. Thanks

[glassfishrobot]

@glassfishrobot Commented hadrianhu said: im having the same issues with glassfish 4, when i replaced with the attached jar, glassfish crashes, does the web-core repl work for glassfish 4 as well?

[glassfishrobot]

@glassfishrobot Commented hadrianhu said: hi kchung, i'm having the same issue with glassfish 4? any know fixes for it? please please help, i have a deadline to finish a project and to switch to glassfish 3 at this point is just not an option ...any thoughts?

[glassfishrobot]

@glassfishrobot Commented kchung said: Folks, I think the fix is already in glassfish 4.0. If you still have the problem, it could be something else. I need a small test case to begin looking for a fix.

[glassfishrobot]

@glassfishrobot Commented taranyury said: I found that this problem appears with JSF 2.2 only. And no matter which Glassfish is (3.1.2 or 4.0)

[glassfishrobot]

@glassfishrobot Commented octabrain said: I have the same issue with JSF 2.2 and Glassfish 4. Richfaces is the only installed framework.

I cannot switch to earlier JSF or Glassfish. It's a severe problem.

[glassfishrobot]

@glassfishrobot Commented kchung said: If the problem appears with JSF 2.2 only, you should file a bug with JSF, so that JSF folks can take a first look.

[glassfishrobot]

@glassfishrobot Commented File: TestServlet.java Attached By: nmehner

[glassfishrobot]

@glassfishrobot Commented File: web-core.jar Attached By: kchung

[glassfishrobot]

@glassfishrobot Commented Issue-Links: blocks GLASSFISH-18505 is related to GLASSFISH-16740

[glassfishrobot]

@glassfishrobot Commented Was assigned to kchung

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-18444