[
https://issues.apache.org/jira/browse/VFS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17798320#comment-17798320
]
Sodrul Bhuiyan commented on VFS-852:
------------------------------------
It's not Http client error because
org.apache.commons.vfs2.provider.webdav4.Webdav4FileObject.executeRequest
method is releasing the connection assuming entire http response had been
consumed (copied in buffer). As stated in the problem the code works fine for
non-ssl.
private HttpResponse executeRequest(HttpUriRequest request) throws
FileSystemException {
HttpResponse var4;
try {
HttpResponse response = this.executeHttpUriRequest(request);
int status = response.getStatusLine().getStatusCode();
if (status == 404 || status == 410) {
throw new FileNotFoundException(request.getURI());
}
if (request instanceof BaseDavRequest) {
((BaseDavRequest)request).checkSuccess(response);
}
var4 = response;
} catch (FileSystemException var10) {
throw var10;
} catch (IOException var11) {
throw new FileSystemException(var11);
} catch (DavException var12) {
throw ExceptionConverter.generate(var12);
} finally {
if (request instanceof HttpRequestBase) {
((HttpRequestBase)request).releaseConnection();
}
}
return var4;
}
> 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
> 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)
