New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 780015 link

Starred by 4 users
Status: WontFix
Owner:
█ allada@chromium.org
Last visit > 30 days ago
Closed: Dec 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

HTTP 301 Redirect Content Download Time Includes Time to Download Target Page

Reported by brentwi...@gmail.com, Oct 31 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce the problem:
1. Open Network tab of Dev Tools
2. Access a URL with HTTP 301 Redirect to another URL (Cached OR Not Cached)
3. Content Download time for 301 Redirect will include time of the actual request for the redirected URL

What is the expected behavior?
Time should just be the time to either request and retrieve HTTP 301, or load from cache

What went wrong?
Time is misleading, incorrect, and caused wasted time trying to figure out the issue. See attached images, note that for 301CachedNetworkTab.png the total load time is less than the time of the 301 and 200 put together.

Did this work before? N/A 

Chrome version: 61.0.3163.100  Channel: stable
OS Version: 10.0
Flash Version: 

I didn't test if HTTP 302 or other responses would have the same issue.
301CachedNetworkTab.png
20.0 KB View Download
301CachedTimingDetails.png
16.2 KB View Download
301CachedHeaders.png
30.2 KB View Download
301NotCachedNetworkTab.png
7.9 KB View Download

Comment 1 by eostroukhov@chromium.org, Nov 1 2017

Owner: allada@chromium.org
Status: Assigned (was: Unconfirmed)

Comment 2 by arturo.a...@roiback.com, Nov 21 2017 

The same is happening for 302 redirects. Got almost crazy trying to figure why a simple redirect (302) was taking several seconds just to download a few bytes.

Tested in:

Linux (Ubuntu 16): 61.0.3163.100 (64 bits)
Windows 10: 62.0.3202.94 (64 bits)

Comment 3 by jnl...@gmail.com, Dec 11 2017 

Same bugs happened for 302 redirects too.

Tested in:
Mac OS X 10.12.6: 62.0.3202.94 (64 bits)

Comment 4 by pfeldman@chromium.org, Dec 13 2017

Status: WontFix (was: Assigned)
Closing due to lack of priority / resources.
►

Sign in to add a comment