[jira] [Closed] (JCLOUDS-905) Expect: 100-Continue + SSL = timeout

["Ignasi Barrera (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JCLOUDS-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ignasi Barrera closed JCLOUDS-905.
----------------------------------
    Resolution: Duplicate

> Expect: 100-Continue + SSL = timeout
> ------------------------------------
>
>                 Key: JCLOUDS-905
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-905
>             Project: jclouds
>          Issue Type: Bug
>          Components: jclouds-blobstore, jclouds-core
>    Affects Versions: 2.0.0, 1.9.0
>            Reporter: Svetoslav Neykov
>
> A bug in the state logic of HttpsUrlConnection used by the default http driver will cause it to block and wait for headers at the wrong time when used with "Expect: 100-Continue" header. When triggered the soTimeout value is not applied on the socket which leads to indefinite block on a read call, only to be cancelled by a server timeout.
> The bug is triggered when using 
>   * Expect: 100-Continue
>   * on Java 7 or Java 8
>   * on SSL connection
>   * connection reuse is enabled (by default)
>   * the stream returned by the call is not closed by the caller
>   * but instead is closed by the GC
> Closing the socket by GC trips the state logic of the "Expect: 100-Continue" feature, eventually leading to failure to parse the http stream coming from the server.
> The problem is not specific to objectstore or even jclouds, but is triggered here because of the use of "Expect: 100-Continue". Seems like using it in combination with SSL connections will inevitably lead to failed requests.
> A jclouds test case which reproduces the behaviour can be found at https://github.com/apache/incubator-brooklyn/blob/master/locations/jclouds/src/test/java/brooklyn/entity/rebind/persister/jclouds/JcloudsExpect100ContinueTest.java
> Note that if wire logging is enabled the problem can't be reproduced (closing streams explicitly?)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)