service worker interception should propagate redirect count to enforce redirect limits

NEW
Unassigned

Status

()

defect
P2
normal
a year ago
a year ago

People

(Reporter: devilex94, Unassigned)

Tracking

(Blocks 1 bug)

59 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

114.58 KB, application/x-gzip
Details
(Reporter)

Description

a year ago
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
(Reporter)

Updated

a year ago
Summary: Preposterou RAM leak. Parent process eating ~6GB RAM → Preposterous RAM leak. Parent process eating ~6GB RAM

Comment 1

a year ago
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 ?
Flags: needinfo?(devilex94)
(Reporter)

Comment 2

a year ago
(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 :/
Flags: needinfo?(devilex94)

Comment 3

a year ago
Based on comment 2 I am marking the issue as New.
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: HTTP
Ever confirmed: true
Product: Firefox → Core
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
Component: Networking: HTTP → DOM: Service Workers
Status: NEW → UNCONFIRMED
Ever confirmed: false
Priority: -- → P2
Needs to be verified.
I visited the link in comment 0 in dev edition 60 and it does indeed reproduce.  It also appears to effect chrome.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Actually, chrome seems to catch the problem in some cases and displays a "too many redirects" error page.
Summary: Preposterous RAM leak. Parent process eating ~6GB RAM → service worker interception should propagate redirect count to enforce redirect limits
You need to log in before you can comment on or make changes to this bug.