multipart/form-data

[19年前 に nrussell nrussell によって更新されました。]

I have written a portlet that extends GenericPortlet. My intent is to wrap the ActionRequest for all classes that extend my new portlet that you could just call the request.getParameter for multipart form data and non multipart form data. The problem is that I am relying on the request.getContentType() to return &quot;multipart/form-data&quot; that is set on the form&#39;s enctype. This works on pluto but I get null from liferay. Is there another way for me to determine this?<br /><br />Thanks

[19年前 に Brett Randall によって更新されました。]

Liferay&#39;s MainServlet deliberately wraps any multipart/form-data request in an UploadServletRequest (which hides the real content-type), to prevent Struts from processing multipart requests (Struts also tries to wrap it in a 2.2 servlet-compliant, home-grown wrapper).<br /><br />I&#39;m not entirely sure why this is done, but it appears that UploadServletRequest attempts to simplify things by encapsulating the entire multipart in Commons fileupload.<br />

[19年前 に Enrique Ruiz によって更新されました。]

Hi, we are trying to upload files using a JSR-168 compliant portlet, but we have found that the ActionRequest.getContentType() method always returns null. We have supossed that it is due to the UploadServletRequest.<br /><br />We believe that this behaviour does not allow to deploy JSR-168 compliant portlets to receive files. Is it true?<br /><br />The portlet specification says:<br /><i>Depending on the underlying web-server/servlet-container and the portal/portlet container implementation, client request HTTP headers may not be always available. Portlets should not rely on the presence of headers to function properly. The<br />PortletRequest interface provides specific methods to access information normally available as HTTP headers: content-length, content-type, accept-language. Portlets should use the specific methods for retrieving those values as the portal/portlet-container implementation may use other means to determine that information.</i><br /><br />We think that Liferay is failing to fulfill this part of the specification.

[19年前 に Brian Chan によって更新されました。]

This was now fixed in CVS 2-3 weeks ago. I think you can get away with just updating util-java/* and upgrading to the latest lib/commons-fileupload.jar plus lib/commons-io.jar from CVS.<br />

[13年前 に Arsh g によって更新されました。]

HI, I am new to liferay...
My html form contains multipart/form data for file uploading.
and also i used liferay captcha " <liferay-ui:captcha url="<%= captchaURL %>" />"
the problem is: for validating captcha i need portlet session(and i get this by using "ActionRequest") but using multipart/form Action Request is converted to the "UploadPortletRequest". so i m enable to validate captcha. plz any one has solution.

[12年前 に Asier Hernández によって更新されました。]

Have you found any solution to this isuue??

I have the same problem with captcha and multipart/form data.

Thanks in advance.

[19年前 に Enrique Ruiz によって更新されました。]

Great&#33;&#33;<br /><br />Thanks.<br />

[18年前 に chiffa chiffa によって更新されました。]

I&#39;m working on JSR 168 portable app and I would like to perform the fileupload independend on the Liferay utilities. I was tried to use commons-fileupload-1.1-dev, but it returns the incorrect file data after uploading file on server in liferay 3.5 case. But Pluto, Gridsphere and uPortal works fine. Please, advice.<br /><br />Can I upload files to portlet on Liferay 3.5 not using the PortalUtil and UploadPortletRequest?<br /><br />Is this issue still exist in Liferay 3.6.1??

[18年前 に zeroconf zeroconf によって更新されました。]

Hi chiffa,<br /><br />I&#39; also working on JSR 168 compliant portlets trying to upload files with common-fileupload lib <br />/Version 1.1-dev) but the file gets corrupted. I&#39; using Liferay 3.6.1 Pro (the prebundled version) with <br />Java 1.5.0_04 on Linux 2.6.13<br /><br />But I think this must be available - how else can you write JSR 168 conform file upload portlets? <br />I haven&#39;t checked if this is already in JIRA bug tracker - but if not I think it should be posted there<br /><br />@bchan<br />are you really shure that this &quot;bug&quot; is fixed ??<br /><br />zeroconf

[18年前 に Enrique Ruiz によって更新されました。]

Hi all, <br /><br />We have fixed this feature in our local copy of the Liferay&#39;s source code. We have tested it with our JSR-168 portlets and it works perfectly. Next, you will found the changes that we have introduced in the Liferay code. All the changes have been done in the com.liferay.util.servlet.UploadServletRequest class.<br /><ul><li>Remove the getContentType() (only for Liferay 3.2. Liferay 3.5+ doesn&#39;t have this method)</li><li>In the constructor, remove the code that parses the InputStream:<br />

    public UploadServletRequest(HttpServletRequest req) throws IOException {
          super(req);
          _params = new LinkedHashMap();
         /*  BEG:  Fix
        try {
            DiskFileUpload diskFileUpload = new LiferayDiskFileUpload(
                new LiferayFileItemFactory(DEFAULT_TEMP_DIR), req);
...
...
                _params.put(fileItem.getFieldName(), fileItems);
            }
        }
        catch (FileUploadException fue) {
            fue.printStackTrace();
        }
                END: Fix */
    }

</li></ul><br />By comment this code, the InputStream of the incoming request is parsed correctly in a Portlet.<br /><br />I suppose the problem was the InputStream was parsed two times.<br /><br />On the other hand, I am sure that to remove the InputStream parsing in the constructor will have side effects if you use of the Struts portlets included with Liferay. We have tested it with our own portlets, using the FileUpload 1.1-dev, and it works perfectly.<br /><br />I have seen some changes in Liferay 4.0 into the cvs but I don&#39;t know if it corrects this problem.<br /><br />Regards.<br />