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

["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