1448979 - service worker interception should propagate redirect count to enforce redirect limits

Status: NEW

(Core :: DOM: Service Workers, defect, P2)

Description

[Mohit Arora]

Attachment: memory-report.json.gz

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180315233128

Steps to reproduce:

I am trying to open this link but the loading never ends!

https://www.flipkart.com/honor-9-lite-glacier-grey-32-gb/p/itmff5zgdeckztpk



Actual results:

Infinite load and RAM fills up within a minute


Expected results:

Website should have loaded perfectly

Comment 1

[David Olah]

Hi Mohit Arora,

I cannot reproduce this issue. I tried on multiple versions, including Firefox 59.

Can you please reproduce and capture the HTTP logs using the following steps: https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging ?

Comment 2

[Mohit Arora]

(In reply to David Olah from comment #1)
> Hi Mohit Arora,
> 
> I cannot reproduce this issue. I tried on multiple versions, including
> Firefox 59.
> 
> Can you please reproduce and capture the HTTP logs using the following
> steps:
> https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging ?

Here, it's compressed zip because original file was ~200MB.
https://drive.google.com/open?id=1WY5Llb81WNw4299WiV4n0bLIYTdY3hkf

I was unable to upload here because of connection issues :/

Comment 3

[David Olah]

Based on comment 2 I am marking the issue as New.

Comment 4

[Honza Bambas (:mayhemer)]

There are two URIs with a following snippet in them (pointing out here to not get lost):
1. .../honor-9-lite-glacier-grey-32
2. .../honor-9-lite-glacier-grey-64


From the log I can see the following:

- content process is navigated to https://www.flipkart.com/honor-9-lite-glacier-grey-32-gb/p/itmff5zgdeckztpk
- we have a cached 301 response, we redirect to https://www.flipkart.com/honor-9-lite-glacier-grey-64-gb/p/itmff5zgdeckztpk
- this redirected channel is intercepted (InterceptedHttpChannel, artificial redirection to the same uri, [2])
- then it's hard for me to track further

- in parallel there is another navigation started on the content process to https://www.flipkart.com/honor-9-lite-glacier-grey-64-gb/p/itmff5zgdeckztpk (as I understand this is the interception channel)
- again, we have a cached response with a 301 redirect to https://www.flipkart.com/honor-9-lite-glacier-grey-32-gb/p/itmff5zgdeckztpk
- we create a regular http channel, and it's later again intercepted and redirected (https://www.flipkart.com/honor-9-lite-glacier-grey-32-gb/p/itmff5zgdeckztpk)

Apparently the server is miss-configured (or was in the past and cached indefinitely - 301 is perma redir we treat with an indefinite freshness, [1]) and instructs us to redirect from 32 -> 64 -> 32.


So, I think we are missing some redirect-loop limit checking in the interception logic?


[1] https://searchfox.org/mozilla-central/rev/f5fb323246bf22a3a3b4185882a1c5d8a2c02996/netwerk/protocol/http/nsHttpResponseHead.cpp#730
[2] https://searchfox.org/mozilla-central/rev/f5fb323246bf22a3a3b4185882a1c5d8a2c02996/netwerk/protocol/http/InterceptedHttpChannel.h#51

Comment 5

[Marion Daly [:mdaly]]

Needs to be verified.

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

I visited the link in comment 0 in dev edition 60 and it does indeed reproduce.  It also appears to effect chrome.

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

Actually, chrome seems to catch the problem in some cases and displays a "too many redirects" error page.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

This very likely was addressed by parent interception but we should be able to point at a test that validates this. The one concern is that I believe for speed we still don't do the full, formal internal redirect, so our redirect count limit might take longer. Setting needinfo on myself to look at the existing WPT tests in this space and our mochitests and validate, and write a test if we don't have one.