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

Issue 721406 link

Starred by 3 users
Status: WontFix
Owner: ----
Closed: Apr 2018
Cc:
█ kapishnikov@chromium.org
mmenke@chromium.org
asanka@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Referrer request for manifest.json files behind http auth fail even in user is authenticated

Reported by robert.r...@improvementdirect.com, May 11 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36

Steps to reproduce the problem:
1. Create a server with basic http authentication
2. Create a basic manifest.json that is served via said server
3. Create a basic HTML page that is served via said server that also references said manifest.json
4. Hit the page
5. Authenticate

What is the expected behavior?
The browser should successfully download the manifest.json.

What went wrong?
The browser doesn't send the http auth headers with the request to get the manifest.json, so you'll get a 401 on the file.

Did this work before? N/A 

Does this work in other browsers? Yes

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

Confirmed on Win10 and Linux (not sure the distro or versions).  FF on Win10 doesn't have this same issue.

Comment 1 by kapishnikov@chromium.org, May 11 2017

Components: Internals>Network>Auth
Labels: Needs-Feedback
Thank you for reporting the issue. Is it possible to get access to the test server to reproduce the problem? Alternatively, could you provide the net-internals log? The instructions can be found here: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

We should check the WWW-Authenticate header fields for the json and the main page 401 responses.

Comment 2 by robert.r...@improvementdirect.com, May 11 2017 

Here's the net-internals log.  Hopefully this suffices!

Thank you!
chrome-net-export-log.json
2.5 MB View Download
Project Member

Comment 3 by sheriffbot@chromium.org, May 11 2017

Cc: kapishnikov@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "kapishnikov@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 4 by kapishnikov@chromium.org, May 11 2017

Labels: Needs-Feedback
I can see only one 401 response that is associated with the manifest.json request. The protection realm is:
WWW-Authenticate: Basic realm="Unauthorized access prohibited"

Does the main HTML page belong to the same realm? Could you start a new session (so that 401 is returned for the HTML page as well) and collect the logs again?

Comment 5 by ranjitkan@chromium.org, May 12 2017

Labels: Needs-Triage-M58

Comment 6 by robert.r...@improvementdirect.com, May 12 2017 

I've attached another log.  I simply hit "cancel" when the uname/pass field came up.

And yes, it should be the same realm :)
chrome-net-export-log.json
150 KB View Download
Project Member

Comment 7 by sheriffbot@chromium.org, May 12 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "kapishnikov@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 8 by kapishnikov@chromium.org, May 12 2017 

Thanks. I can see now that the Authorization header is automatically sent for vizury_data.json (as it should be) but not for manifest.json. Both json files are located on the same URL hierarchy level as the HTML page that references them.

asanka, do you know why manifest.json is treated differently than other resources in terms of automatic inclusion of the Authorization header in the URL request?

Comment 9 by hdodda@chromium.org, May 15 2017

Labels: TE-NeedsTriageHelp

Comment 10 by mmenke@chromium.org, Apr 18 2018

Cc: mmenke@chromium.org
Components: Blink>Storage>AppCache
Been a while since this was reported, but manifest.json implies this is an AppCache issue.

Comment 11 by mmenke@chromium.org, Apr 18 2018

Status: WontFix (was: Unconfirmed)
It looks like the request in question had the DO_NOT_SEND_AUTH_DATA flag attached.  This issue is old enough that I think we should just close it, but this looks like it was not a network issue, but rather an issue with whatever issued the request telling us not to use auth.  The request may have been in an uncredentialed context.
►

Sign in to add a comment