[jira] [Commented] (JCR-5009) webdav4s is not working with multiple TLS Record Layer segments

["Julian Reschke (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCR-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17798314#comment-17798314 ] 

Julian Reschke commented on JCR-5009:
-------------------------------------

Could you clarify why you think this is a bug in Jackrabbit? (As opposed to the layers above or Apache HttpClient?).

> webdav4s is not working with multiple TLS Record Layer segments
> ---------------------------------------------------------------
>
>                 Key: JCR-5009
>                 URL: https://issues.apache.org/jira/browse/JCR-5009
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>    Affects Versions: 2.21.21
>            Reporter: Sodrul Bhuiyan
>            Priority: Major
>
> We're trying to use webdav over SSL using webdav4s provider. We're running into connection closed error because the connection had been released from the finally block as part of org.apache.commons.vfs2.provider.webdav4.Webdav4FileObject#executeRequest method. The issue becomes visible from org.apache.commons.vfs2.provider.webdav4.Webdav4FileObject#getProperties(org.apache.commons.vfs2.provider.GenericURLFileName, int, org.apache.jackrabbit.webdav.property.DavPropertyNameSet, boolean) method which we're using. I would imagine it'd also be an issue from org.apache.commons.vfs2.provider.webdav4.Webdav4FileObject#doListChildrenResolved method. As both of these methods try to get the body of the response after the connection had been released from executeRequest method.
> The design assumption was that the entire data (http response) was consumed before closing. However while debugging the issue we have found that TLS transmission containing the application data had been broken up into multiple TLS Record Layer Segments (Fragments as designed). While filling up the buffer from SSL Socket it stopped after the 1st TLS record layer, which only contained the http headers as it hit the end of that stream (fragment). Non-ssl transaction doesn't have fragmentation so buffer fills up entire response at once thus doesn't cause the connection closed error.
> I'd imagine the fix would be to implement an overloading executeRequest method for keeping the connection open and close it after retrieving the body of the response from getProperties and doListChildrenResolved method.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)