Fetch API rejects remote requests with NetworkError when page hosted on localhost

RESOLVED INVALID

Status

()

Core
DOM
RESOLVED INVALID
2 years ago
a year ago

People

(Reporter: David Evans, Unassigned)

Tracking

48 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

2 years ago
Created attachment 8781415 [details]
fetch_localhost_error.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160726073904

Steps to reproduce:

Host the attached page on localhost and request using Firefox.


Actual results:

Firefox rejects the fetch and gives error message "TypeError: NetworkError when attempting to fetch resource".

I don't see any fetch requests in either the dev tools, or Wireshark. There doesn't seem to be any further debugging available to diagnose.


Expected results:

Text should appear in the output div, and no error should appear in the error div.

Hosting the same page at http://jsbin.com/yowebiyigi/edit?html,output or any other endpoint gives the expected output - the text appears in the div, and I see the fetch request being made in dev tools.

Chrome works correctly in both scenarios which implies both the localhost and remote server is configured correctly for CORS etc (but FF never seems to query the remote anyway).

Same result in FF51. I have only tested on Windows 7.

Comment 1

2 years ago
What do you mean by localhost? What's in the address bar?

Comment 3

2 years ago
And this works with XMLHttpRequest? That does seem rather strange. Josh, is this anything you could help with?
Flags: needinfo?(josh)
(Reporter)

Comment 4

2 years ago
Created attachment 8781885 [details]
fetch_localhost_error_with_added_xhr.html
(Reporter)

Comment 5

2 years ago
Yes, XHR works as expected while fetch fails. See second attachment for test procedure.

Comment 6

2 years ago
I can't reproduce.  Is it possible you have a service worker installed on http://localhost from previous development?
Component: Untriaged → DOM
Flags: needinfo?(bbcrddave)
Product: Firefox → Core

Comment 7

2 years ago
Created attachment 8782983 [details]
Screenshot 2016-08-19 13.24.54.png

Screenshot of the test case working on my machine.

Can you post your about:support as well?
Flags: needinfo?(josh)

Comment 8

2 years ago
I can reproduce this issue on FF 48.0.1 on OSX 10.11.6 from a WebExtension I am working on.

Comment 9

2 years ago
Can you upload an example WebExtension somewhere that demonstrates the problem?
Flags: needinfo?(t.rebours)

Comment 10

2 years ago
I'm written a sample WebExtension here: https://github.com/tex0l/fetch-sample-bug
It is based on this example: https://github.com/mdn/webextensions-examples/tree/master/commands
Flags: needinfo?(t.rebours)

Comment 11

2 years ago
Thanks!  I'll try to reproduce some time in the next few days.
Flags: needinfo?(bkelly)

Comment 12

2 years ago
Ok thanks ! (by the way, sorry for the typo)

Comment 13

2 years ago
(In reply to t.rebours from comment #10)
> I'm written a sample WebExtension here:
> https://github.com/tex0l/fetch-sample-bug
> It is based on this example:
> https://github.com/mdn/webextensions-examples/tree/master/commands

So this extension tries to read two different URLs:

1) 'http://localhost:8000/'
2) 'https://www.google.fr/'

The google.fr works, but the localhost rejects with a NetworkError for me.

The localhost URL is rejecting since it does not provide CORS headers.  (I am just using python -m SimpleHTTPServer for my localhost.)  If I change the addon to use mode:'no-cors' then the fetch() completes successfully.

I think all this is working correctly.

Note, this is also different from the original bug report here.  This bug is for hosting your site on localhost host and trying to access a non-localhost resource.

Can you confirm that you are seeing the same thing?  Or are you getting an error on google.fr?
Flags: needinfo?(bkelly) → needinfo?(t.rebours)

Comment 14

2 years ago
My bad...
I was porting an extension from chrome to FF, and I don't have the problem with my localhost server not providing CORS headers there.

When I set mode:'no-cors' in fetch, I get an type:'opaque' Response object, but you are right this is another problem entirely and is probably located between my chair and my computer.

Thank you for your help !
Flags: needinfo?(t.rebours)
(Reporter)

Comment 15

2 years ago
Sorry for the long delay - I have been on holiday.

I checked for service workers, there was one for a different scope (ie http://localhost/some_other_scope/) which it was my understanding should not affect this. I deleted that, and the two others for other domains for good measure, and restarted Firefox - no change :(

Attaching about:support.
Flags: needinfo?(bbcrddave)
(Reporter)

Comment 16

2 years ago
Created attachment 8787087 [details]
about_support.txt

Comment 17

2 years ago
Comment on attachment 8787087 [details]
about_support.txt

> network.http.referer.XOriginPolicy: 1

Please try setting network.http.referer.XOriginPolicy to 0 in about:config.
Flags: needinfo?(bbcrddave)
(Reporter)

Comment 18

2 years ago
Yes, that fixes the NetworkError - awesome!
Is this the expected behaviour?
Flags: needinfo?(bbcrddave)

Comment 19

2 years ago
(In reply to David Evans from comment #18)
> Yes, that fixes the NetworkError - awesome!
> Is this the expected behaviour?

Its a non-standard configuration.  Perhaps you had this pref flipped by one of these addons?

  https://addons.mozilla.org/en-US/firefox/addon/smart-referer/
  https://addons.mozilla.org/en-US/firefox/addon/toggle-referer/
  https://addons.mozilla.org/firefox/addon/refcontrol/

Anyway, I'm glad we could track down the issue.  Since this was a configuration problem I'm going to mark this as INVALID for now.  Thanks for the report!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID

Comment 20

a year ago
Just as information: fetch some URLs could fail in script content (WebExtension context) if no adequate permissions are requested in manifest.json. See https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Match_patterns
You need to log in before you can comment on or make changes to this bug.