[
https://issues.apache.org/jira/browse/VFS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17841114#comment-17841114
]
Florian Kolbe commented on VFS-852:
-----------------------------------
Is this the same issue?
Though we are not using TLS.
{noformat}
Caused by: java.net.SocketException: Socket closed
at java.net.SocketInputStream.socketRead0(Native Method) ~[?:?]
at java.net.SocketInputStream.socketRead(SocketInputStream.java:115)
~[?:?]
at java.net.SocketInputStream.read(SocketInputStream.java:168) ~[?:?]
at java.net.SocketInputStream.read(SocketInputStream.java:140) ~[?:?]
at
org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
~[httpcore-4.4.13.jar:4.4.13]
at
org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
~[httpcore-4.4.13.jar:4.4.13]
at
org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:280)
~[httpcore-4.4.13.jar:4.4.13]
at
org.apache.http.impl.io.ChunkedInputStream.getChunkSize(ChunkedInputStream.java:248)
~[httpcore-4.4.13.jar:4.4.13]
at
org.apache.http.impl.io.ChunkedInputStream.nextChunk(ChunkedInputStream.java:222)
~[httpcore-4.4.13.jar:4.4.13]
at
org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:183)
~[httpcore-4.4.13.jar:4.4.13]
at
org.apache.http.conn.EofSensorInputStream.read(EofSensorInputStream.java:135)
~[httpclient-4.5.13.jar:4.5.13]
at
org.apache.xerces.impl.XMLEntityManager$RewindableInputStream.read(Unknown
Source) ~[org.apache.xerces-2.9.0.jar:?]
at org.apache.xerces.impl.io.UTF8Reader.read(Unknown Source)
~[org.apache.xerces-2.9.0.jar:?]
at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
~[org.apache.xerces-2.9.0.jar:?]
at org.apache.xerces.impl.XMLEntityScanner.skipSpaces(Unknown Source)
~[org.apache.xerces-2.9.0.jar:?]
at
org.apache.xerces.impl.XMLDocumentScannerImpl$TrailingMiscDispatcher.dispatch(Unknown
Source) ~[org.apache.xerces-2.9.0.jar:?]
at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source) ~[org.apache.xerces-2.9.0.jar:?]
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
~[org.apache.xerces-2.9.0.jar:?]
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
~[org.apache.xerces-2.9.0.jar:?]
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
~[org.apache.xerces-2.9.0.jar:?]
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
~[org.apache.xerces-2.9.0.jar:?]
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
~[org.apache.xerces-2.9.0.jar:?]
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:122)
~[?:?]
at
org.apache.jackrabbit.webdav.xml.DomUtil.parseDocument(DomUtil.java:104)
~[jackrabbit-webdav-2.21.25.jar:?]
at
org.apache.jackrabbit.webdav.client.methods.BaseDavRequest.getResponseBodyAsDocument(BaseDavRequest.java:69)
~[jackrabbit-webdav-2.21.25.jar:?]
at
org.apache.jackrabbit.webdav.client.methods.BaseDavRequest.getResponseBodyAsMultiStatus(BaseDavRequest.java:87)
~[jackrabbit-webdav-2.21.25.jar:?]
at
org.apache.commons.vfs2.provider.webdav4.Webdav4FileObject.getProperties(Webdav4FileObject.java:508)
~[commons-vfs2-jackrabbit2-2.9.0.jar:2.9.0]
at
org.apache.commons.vfs2.provider.webdav4.Webdav4FileObject.getProperties(Webdav4FileObject.java:497)
~[commons-vfs2-jackrabbit2-2.9.0.jar:2.9.0]
at
org.apache.commons.vfs2.provider.webdav4.Webdav4FileObject.getProperty(Webdav4FileObject.java:531)
~[commons-vfs2-jackrabbit2-2.9.0.jar:2.9.0]
at
org.apache.commons.vfs2.provider.webdav4.Webdav4FileObject.getProperty(Webdav4FileObject.java:536)
~[commons-vfs2-jackrabbit2-2.9.0.jar:2.9.0]
at
org.apache.commons.vfs2.provider.webdav4.Webdav4FileObject.isDirectory(Webdav4FileObject.java:569)
~[commons-vfs2-jackrabbit2-2.9.0.jar:2.9.0]
at
org.apache.commons.vfs2.provider.webdav4.Webdav4FileObject.doGetType(Webdav4FileObject.java:340)
~[commons-vfs2-jackrabbit2-2.9.0.jar:2.9.0]
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:1375)
~[commons-vfs2-2.9.0.jar:2.9.0]
... 31 more
{noformat}
> 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)
