[
https://issues.apache.org/jira/browse/VFS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846311#comment-17846311
]
Gary D. Gregory commented on VFS-852:
-------------------------------------
Releasing is definitively on my to-do list. Maybe within a week or two.
> webdav4s is not working with multiple TLS Record Layer segments
> ---------------------------------------------------------------
>
> Key: VFS-852
> URL: https://issues.apache.org/jira/browse/VFS-852
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.9.0
> 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)
