You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "ZFabrik (Created) (JIRA)" <ji...@apache.org> on 2012/02/21 12:05:34 UTC

[jira] [Created] (JCR-3240) Wrong Content-Type when uploading via MAC OS Webdav client

Wrong Content-Type when uploading via MAC OS Webdav client
----------------------------------------------------------

                 Key: JCR-3240
                 URL: https://issues.apache.org/jira/browse/JCR-3240
             Project: Jackrabbit Content Repository
          Issue Type: Bug
          Components: jackrabbit-jcr-server
    Affects Versions: 2.2.5
         Environment: Jetty 6.1.22, Mac OS X Webdav Client: "WebDAVFS/1.8.3 (01838000) Darwin/10.8.0 (x86_64)"
            Reporter: ZFabrik


The problem seems to be caused by the way Jetty and Jackrabbit interoperates with each other conditioned by a peculiarity of the MAC OS Webdav client:

0) Jetty resuses the request input-stream instance: org.mortbay.jetty.HttpParser$Input for new requests.

1) A PROPFIND arrives with Content-Length=123 for example. It seems however that Jackrabbit is not interested into the xml content at all.
2) A PUT arrives with Content-Length=0 (seem to be a peculiarity of the MAC OS Webdav client, I have no clue why MAC OS is doing this. The real payload will be send a "few" requests later within another PUT).
3) Jetty reuses the InputStream which contains the xml content from the previous PROPFIND request!
4) Jackrabbit uses Apache Tika in order to sleuth the content type and finds the xml from the previous request (ignoring the fact the the Content-Length is 0)

The workaround I found proves my findings. I extended Jackrabbit's org.apache.jackrabbit.j2ee.SimpleWebdavServlet
containing an overwritten service() method:

    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    	super.service(request, response);
    	
    	// make sure input stream is eaten up
    	ServletInputStream ins = request.getInputStream();
    	while (ins.read() != -1);
    }

Now the input-stream is always eaten up so that the following request will get a clean input-stream.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (JCR-3240) Wrong Content-Type when uploading via MAC OS Webdav client

Posted by "Julian Reschke (Commented) (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JCR-3240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13212518#comment-13212518 ] 

Julian Reschke commented on JCR-3240:
-------------------------------------

a) Jackrabbit not looking at the input stream for PROPFIND is strange; we should find out what's going on here.

b) Jetty re-using the stream is weird; I'd be surprised if the servlet spec allows that behavior...
                
> Wrong Content-Type when uploading via MAC OS Webdav client
> ----------------------------------------------------------
>
>                 Key: JCR-3240
>                 URL: https://issues.apache.org/jira/browse/JCR-3240
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-jcr-server
>    Affects Versions: 2.2.5
>         Environment: Jetty 6.1.22, Mac OS X Webdav Client: "WebDAVFS/1.8.3 (01838000) Darwin/10.8.0 (x86_64)"
>            Reporter: ZFabrik
>
> The problem seems to be caused by the way Jetty and Jackrabbit interoperates with each other conditioned by a peculiarity of the MAC OS Webdav client:
> 0) Jetty resuses the request input-stream instance: org.mortbay.jetty.HttpParser$Input for new requests.
> 1) A PROPFIND arrives with Content-Length=123 for example. It seems however that Jackrabbit is not interested into the xml content at all.
> 2) A PUT arrives with Content-Length=0 (seem to be a peculiarity of the MAC OS Webdav client, I have no clue why MAC OS is doing this. The real payload will be send a "few" requests later within another PUT).
> 3) Jetty reuses the InputStream which contains the xml content from the previous PROPFIND request!
> 4) Jackrabbit uses Apache Tika in order to sleuth the content type and finds the xml from the previous request (ignoring the fact the the Content-Length is 0)
> The workaround I found proves my findings. I extended Jackrabbit's org.apache.jackrabbit.j2ee.SimpleWebdavServlet
> containing an overwritten service() method:
>     @Override
>     protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
>     	super.service(request, response);
>     	
>     	// make sure input stream is eaten up
>     	ServletInputStream ins = request.getInputStream();
>     	while (ins.read() != -1);
>     }
> Now the input-stream is always eaten up so that the following request will get a clean input-stream.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira