Measure how large HTTP redirect chains are for successful loads |
|||||
Issue descriptionIn https://github.com/whatwg/fetch/issues/576 , Apple raised a concern of behaviour difference between Chrome/Firefox and Safari, namely, with how many HTTP redirects are permitted before aborting the connection. Safari (and the underlying CFNetwork) use a redirect limit of 16, while Chrome and Firefox implement a limit of 20. The choice of 20 was not empirically done (for Chrome, it inherited from Firefox, and Firefox inherited a limit of 10 from Lynx, and then doubled it after some compat issues), although all of these are greater than the HTTP spec's recommendation of 5. To align behaviour, we should understand what compatibility risk there is from changing/reducing our limit. One notable behaviour difference is that we include synthetic redirects in the count - redirects generated by HSTS (HTTP -> HTTPS rewrites) or from extensions. This makes it difficult to assess the compatibility risk with Safari, which does not count such redirects in its limits.
,
Aug 14 2017
,
Aug 22 2017
From PageLoad.Navigation.RedirectChainLength: over all page loads, 16 is the 99.9995% percentile. 20 is the 99.999997% percentile. Looking only at page loads that had at least one redirect, 16 is the 99.991% percentile and 20 is the 99.999988% It would be interesting to do an experiment where we increased the limit, but given these numbers there may be no point. My guess would be that decreasing the limit to 16 would have no statistically significant impact on our metrics. However, it will inevitably break somebody's use case. A/B testing will make those manually-detected problems hard to diagnose. How about ticking down the limit 1 at a time over the course of 4 releases?
,
Aug 22 2017
ricea: Thanks for the suggestions, but I'm not sure that offers a compelling advantage over our Intent process, which would instead move from 20->16 after measuring. I'm aware of the navigation redirect limits, but I'm concerned for subresources, so a lower-level metric seems better. You mentioned increasing the limit - but the proposal is to decrease the limit (from 20 to 16). As our Intent process helps reduce surprises, and there's no proposal for A/B testing here, I think we'll be fine.
,
Aug 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/021236f9262576b52303809d9d5468c100554fee commit 021236f9262576b52303809d9d5468c100554fee Author: Ryan Sleevi <rsleevi@chromium.org> Date: Fri Aug 25 17:00:43 2017 Measure the length of the redirect chain from the //net layer https://github.com/whatwg/fetch/issues/576 highlights a browser difference, in that Firefox and Chromium limit redirect chains to 20 redirects, while Safari limits to 16. Chromium inherited Firefox's limit, and Firefox initially started with Lynx's limit of 10, and then doubled it when some sites failed to load. The HTTP spec itself suggested 5. In order to explore converging implementations on Safari's limit, measure the length of the redirect chain when processing redirects. BUG= 755117 Change-Id: I9b1ba8d33ad87d5f467527b8e08eb9df054dee66 Reviewed-on: https://chromium-review.googlesource.com/627436 Commit-Queue: Ryan Sleevi <rsleevi@chromium.org> Reviewed-by: Matt Menke <mmenke@chromium.org> Reviewed-by: Charlie Harrison <csharrison@chromium.org> Reviewed-by: Ilya Sherman <isherman@chromium.org> Cr-Commit-Position: refs/heads/master@{#497443} [modify] https://crrev.com/021236f9262576b52303809d9d5468c100554fee/net/url_request/url_request.cc [modify] https://crrev.com/021236f9262576b52303809d9d5468c100554fee/tools/metrics/histograms/histograms.xml
,
Nov 30 2017
Forgot to close this out as Fixed/Landed
,
Jul 6
,
Jul 6
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by rsleevi@chromium.org
, Aug 14 2017