1457768 - miss redirect request after 302 with range header

Status: NEW

(Core :: Networking: HTTP, defect, P3)

Description

[Ruslan Erofeev]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.1 Safari/605.1.15

Steps to reproduce:

In current version FF(User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0) I don't see redirect after GET-request with range header and status 302.

In Chrome(65.0.3325.181) this redirect request is present.



Actual results:

- Send GET-request with range header and status 302:

Response headers:
Access-Control-Allow-Headers: origin, range
Access-Control-Allow-Methods: GET, HEAD, OPTIONS
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: X-Dfsid, Location, Server, range
Connection: keep-alive
Content-Length: 154
Content-Type: text/html
Date: Sun, 29 Apr 2018 11:40:49 GMT
Location: https://storage32.dfs.ivi.ru/d…edb29/video_0.mp4?redirected=1
Server: nginx
X-Dfsid: dfs-dtln-10

- Redirect request on location from response headers is missing.




Expected results:

- Send GET-request with range header, which has status 302 and location in response header.
- Send GET-request on location from first request with same range header.

Comment 1

[:Gijs (he/him)]

Did you intend to mark this issue as security-sensitive? Off-hand, I don't see a security aspect to it.

Separately, can you post the request headers, and/or a test site to reproduce this with? That would simplify triaging this so the right people can look at it. Also, have you tried the same procedure in Firefox Nightly? ( https://nightly.mozilla.org/ )

Comment 2

[Ruslan Erofeev]

> Did you intend to mark this issue as security-sensitive? Off-hand, I don't see a security aspect to it.

Yes, of course. I wrongly chose this checkbox. I couldn't change it after.

> Also, have you tried the same procedure in Firefox Nightly?

Yes, this situation repeats also.

> can you post the request headers

Request header:

Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Connection: keep-alive
Host: central.dfs.ivi.ru
Origin: https://gambit2.test.ivi.ru
Range: bytes=968-14967
Referer: https://gambit2.test.ivi.ru/player/?app_version=870&id=99906
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Firefox/60.0

Comment 3

[Valentin Gosu [:valentin] (he/him) {{ AFK in July }}]

Discussion withing Necko led to the suggestion that we should send a request to the new location, but drop the range header.

Comment 4

[paul-louis]

Any updates on this bug? I'm wondering the reason why the range header should be dropped. It breaks useful use cases like a range request on a media file redirected on CDN-side (e.g. for load-balancing). In that situation, Firefox downloads the whole media file, but Chrome for instance properly fetches the range.

Comment 5

[Honza Bambas (:mayhemer)]

Ruslan, how exactly is the request originated?  Is it an XHR or a media request (from a <video> tag), or something else?  Thanks.  

Also, a life public (or somehow private) test case would help fixing this.

Comment 6

[Honza Bambas (:mayhemer)]

Releasing this bug for now in case someone else finds time to work on it sooner than me.