Two questions about CronetHttpURLConnection: MessageLoop and Redirect

[danny1...@gmail.com]

Hi, i'm a user of Cronet, there are two issues in my use of the CronetHttpURLConnection as follows:

Q1, if my server doesn't return any data after the connection is established, I directly call getResponseCode() and it will always block.

Declares that the above screenshot code is the old version, the latest mainline version has the same logic.

Does the block meet expectation in my test scenario? Does it need to be controlled by readtimeout here？

Q2, why don't we do a http to https redirect, since our Cronethttpurlconnection can handle both http and https. 

Is this meant to align with the native HttpURLConnection and HttpsURLConnection? If I want to do different protocol redirects, should I reopen a CronetHttpURLConnection?

Could you please kindly help to explain? Thanks!

Best Wishes,

Wang Wang

[Helen Li]

+net-dev@ (you might get a faster response there for cronet-related issues)

CronetHttpURLConnection supports read timeout (see https://cs.chromium.org/chromium/src/components/cronet/android/java/src/org/chromium/net/urlconnection/CronetHttpURLConnection.java?rcl=4f6f43dc5122f5404a9b7b4d696251eada4d4627&l=422) , but not connect timeout (see the reason listed here: https://cs.chromium.org/chromium/src/components/cronet/android/java/src/org/chromium/net/urlconnection/CronetHttpURLConnection.java?rcl=4f6f43dc5122f5404a9b7b4d696251eada4d4627&l=405). 

If your server doesn't accept the connection, getResponseCode() will always block indefinitely.

For the redirect behavior, it is done to match Android platform's implementation. You can read the motivation in the original CL: https://codereview.chromium.org/1404423006 

CronetHttpURLConnection is a wrapper on top of Cronet's async APIs (i.e. UrlRequest). CronetHttpURLConnection has limited features compared to Cronet's async APIs and is largely done to match the platform's implementation for compatibility.  It's recommended to use Cronet's async APIs directly. For example, it's much easier to implement app-level connect/read timeout by setting a timer and waiting on UrlRequest's listener callbacks. It's also easier to customize the redirect behavior that you want.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/5df68980-f1ca-4376-935c-d5d128d8767d%40chromium.org.

[Helen Li]

Slight correction: getResponseCode() will always block until timeouts set within the Chrome network stack kick in. For example, TransportConnectJob::kTimeoutInSeconds is one of such timeout, once that's hit, you will get ERR_CONNECTION_TIMED_OUT.

One way to debug your issue is to use NetLog via CronetEngine#startNetLogToFile, and upload the file to chrome://net-internals#import for visualization.

[danny1...@gmail.com]

Helen, 

Thank you so much for the detailed explanation.

I would like to explain again the specific scenario of the getResponseCode() block, that is, the connection has been established successfully, but the server does not reply to any header or body data. In this case if I want to disconnect this connection as soon as possible, is it desirable to control it through ReadTimeout?

Redirect related issues I already understand, and I'm willing to share with you that we are also using Cronet's UrlRequest, as you said UrlRequest has a good experience in terms of ease of use and performance.

在 2018年5月4日星期五 UTC+8上午12:41:56，Helen Li写道：

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Helen Li]

I would like to explain again the specific scenario of the getResponseCode() block, that is, the connection has been established successfully, but the server does not reply to any header or body data. In this case if I want to disconnect this connection as soon as possible, is it desirable to control it through ReadTimeout?

Yes, if you setReadTimeout(), the value should be respected by CronetHttpURLConnection. If not, please file a bug on https://crbug.com, and I will look into it.

Redirect related issues I already understand, and I'm willing to share with you that we are also using Cronet's UrlRequest, as you said UrlRequest has a good experience in terms of ease of use and performance.

That's good to know.  Is there a reason that you are also using CronetHttpURLConnection?

 

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/ae662c46-00bf-4ce8-9409-2697238b7667%40chromium.org.

[danny1...@gmail.com]

Yes, if you setReadTimeout(), the value should be respected by CronetHttpURLConnection. If not, please file a bug on https://crbug.com, and I will look into it.

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=840187 to track my issue.

  Is there a reason that you are also using CronetHttpURLConnection?

Many of our projects are based on HttpURLConnection before we use cronet.

在 2018年5月4日星期五 UTC+8上午1:43:13，Helen Li写道：

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.