[dart-misc] Potentially breaking change in HttpClient behavior

['Alexander Aprelev' via Dart Misc]

We have recently improved performance of HttpClient open
<https://api.dartlang.org/stable/2.0.0/dart-io/HttpClient/open.html>/openUrl
<https://api.dartlang.org/stable/2.0.0/dart-io/HttpClient/openUrl.html>
methods so that they return a connection right away, rather than schedule
it to be returned on the next event cycle. Scheduling was done to help with
the case where a cached connection went stale, closed by the server, but
was not marked as closed by the client yet. This delay was removed based on
the assumption that a well-formed client has retry logic built-in, which
retries the connect request if the given connection was stale or gets
closed before the client manages to connect.

Given that we want to emphasize that having a retry mechanism is rather
important to ensure a given http client is robust. Below is a simple
example of getUrlWithRetry. In general, you should take into account
whether it is safe to retry a failed http request as you might not want to
automatically retry a POST http request that has side-effects on the
server, and whether retry attempts should be progressively delayed.

Future<List<String>> getUrlWithRetry(HttpClient httpClient, Uri url,

{int maxRetries: 5}) async {

for (var attempt = 0; attempt < maxRetries; attempt++) {

try {

final request = await httpClient.openUrl('GET', url);

final response = await request.close();

return await response

.transform(new Utf8Decoder(allowMalformed: true)).toList();

} catch (e) {

// ...

}

}

}

[mythz]

Does this still allow us to modify the HTTP Request before it's sent? e.g.
are we still able to do stuff like:

final request = await httpClient.openUrl('GET', url);
req.headers.add(HttpHeaders.authorizationHeader, 'Bearer ' + bearerToken);
req.headers.chunkedTransferEncoding = false;
req.write(bodyStr);

Post by 'Alexander Aprelev' via Dart Misc
We have recently improved performance of HttpClient open
<https://api.dartlang.org/stable/2.0.0/dart-io/HttpClient/open.html>/
openUrl
<https://api.dartlang.org/stable/2.0.0/dart-io/HttpClient/openUrl.html>
methods so that they return a connection right away, rather than schedule
it to be returned on the next event cycle. Scheduling was done to help with
the case where a cached connection went stale, closed by the server, but
was not marked as closed by the client yet. This delay was removed based on
the assumption that a well-formed client has retry logic built-in, which
retries the connect request if the given connection was stale or gets
closed before the client manages to connect.
Given that we want to emphasize that having a retry mechanism is rather
important to ensure a given http client is robust. Below is a simple
example of getUrlWithRetry. In general, you should take into account
whether it is safe to retry a failed http request as you might not want to
automatically retry a POST http request that has side-effects on the
server, and whether retry attempts should be progressively delayed.
Future<List<String>> getUrlWithRetry(HttpClient httpClient, Uri url,
{int maxRetries: 5}) async {
for (var attempt = 0; attempt < maxRetries; attempt++) {
try {
final request = await httpClient.openUrl('GET', url);
final response = await request.close();
return await response
.transform(new Utf8Decoder(allowMalformed: true)).toList();
} catch (e) {
// ...
}
}
}

['Alexander Aprelev' via Dart Misc]

Right, nothing changes in the way how HttpRequest can be modified before it
is sent.

Post by mythz
Does this still allow us to modify the HTTP Request before it's sent? e.g.
final request = await httpClient.openUrl('GET', url);
req.headers.add(HttpHeaders.authorizationHeader, 'Bearer ' + bearerToken);
req.headers.chunkedTransferEncoding = false;
req.write(bodyStr);

Post by 'Alexander Aprelev' via Dart Misc
We have recently improved performance of HttpClient open
<https://api.dartlang.org/stable/2.0.0/dart-io/HttpClient/open.html>/
openUrl
<https://api.dartlang.org/stable/2.0.0/dart-io/HttpClient/openUrl.html>
methods so that they return a connection right away, rather than schedule
it to be returned on the next event cycle. Scheduling was done to help with
the case where a cached connection went stale, closed by the server, but
was not marked as closed by the client yet. This delay was removed based on
the assumption that a well-formed client has retry logic built-in, which
retries the connect request if the given connection was stale or gets
closed before the client manages to connect.
Given that we want to emphasize that having a retry mechanism is rather
important to ensure a given http client is robust. Below is a simple
example of getUrlWithRetry. In general, you should take into account
whether it is safe to retry a failed http request as you might not want to
automatically retry a POST http request that has side-effects on the
server, and whether retry attempts should be progressively delayed.
Future<List<String>> getUrlWithRetry(HttpClient httpClient, Uri url,
{int maxRetries: 5}) async {
for (var attempt = 0; attempt < maxRetries; attempt++) {
try {
final request = await httpClient.openUrl('GET', url);
final response = await request.close();
return await response
.transform(new Utf8Decoder(allowMalformed: true)).toList();
} catch (e) {
// ...
}
}
}
--

For more ways to connect visit https://www.dartlang.org/community
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/dartlang.org/d/msgid/misc/fd144206-96dc-4e47-9a61-005a87898afb%40dartlang.org
<https://groups.google.com/a/dartlang.org/d/msgid/misc/fd144206-96dc-4e47-9a61-005a87898afb%40dartlang.org?utm_medium=email&utm_source=footer>
.