[jira] [Commented] (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:comment-tabpanel&focusedCommentId=14539775#comment-14539775 ] 

Ignasi Barrera commented on JCLOUDS-905:
----------------------------------------

Does this only happen with SSL connections? The default driver manages clear text and SSL connections the same way.

The content stream life cycle in jclouds does not depend on the HTTP driver being used. When the response is received, we check if it was successful or failed (or it is a redirect, etc) [here|https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/BaseHttpCommandExecutorService.java#L100-L107]. That method also takes care of configuring the redirect and handling the error, and in that case it also [releases the content stream|https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/BaseHttpCommandExecutorService.java#L134-L136] because the current request has been completely processed.

However, if the response is succesful (2xx status code), we intentionally don't close the stream (it might not be repeatable) and [just return|https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/BaseHttpCommandExecutorService.java#L123] so the response body can be deserialized into the high level Java objets used by the provider APIs. The _response parsers_ (the entities in jclouds that deserialize the responses) take care of closing the stream once they're done with it.

Looking at the spec of the 100 status code, it looks like the response does not carry a body that should be deserialized, as the server still expects the request to be completed, so the current {{statusCode >= 300}} check seems to be inaccurate.

Should it be safe to always close the content stream on 1xx responses? The HTTP drivers already close the content stream if the response is a 204, but it looks like having 1xx response streams closed by defaut in the {{BaseHttpCommandExecutorService}} is the way to go, since those responses are unlikely to be used in the higher level provider APIs.

Do you want to try implementing such a change and test if it works?

> 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
>    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)