[
https://issues.apache.org/jira/browse/VFS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846341#comment-17846341
]
Florian Kolbe commented on VFS-852:
-----------------------------------
Something weird about reading the InputStream from the Entity. Maybe even a bug
in {{org.apache.http}} ?
Kind of hacky, but I made a workaround that pre-reads the InputStream into BAIS
while ignoring the Exception.
{code}
Document getResponseBodyAsDocument(HttpEntity entity) throws IOException {
if (entity == null) {
return null;
} else {
InputStream in = entity.getContent();
try {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
try {
IOUtils.copy(in, bos);
} catch (SocketException e) {
if (logger.isDebugEnabled()) {
logger.debug(e.toString(), e);
}
}
return DomUtil.parseDocument(new
ByteArrayInputStream(bos.toByteArray()));
} catch (ParserConfigurationException ex) {
throw new IOException("XML parser configuration error", ex);
} catch (SAXException ex) {
throw new IOException("XML parsing error", ex);
} finally {
in.close();
}
}
}
{code}
It does not address the actual problem, though.
> 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)
