1338056 - firefox returns cached response but doesn't tell me that's a cached response

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P3)

Description

[sunfeng32]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

I used fetch to send a request with headers {Authorization: 'Bearer xxxxx', cache: 'force-cache'}


Actual results:

Got 400 Bad Request with error message 'malformed authorization header', only in firefox.
After check, the request never sent out but got blocked by firefox. The request header in `Network Panel` didn't contain the `cache` part, that's why this problem cost me much time to locate. 

After I remove the `cache` part in header, it works.


Expected results:

Should access my api server normally like other browsers.
Should list the `cache` header in `Network Panel`.

Comment 1

[sunfeng32]

It seems

Comment 2

[Dragana Damjanovic [:dragana]]

I have tried it with Nightly and I do see 'cache' header. (but this can be a dup of 1273503).

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

It would be helpful to have some more information:

1) What version of firefox is this?
2) Please show the entire fetch() call.  What other options were passed?  What mode is this?
3) Is this cross-origin?

A working example would be most helpful.

Thanks.

Comment 4

[sunfeng32]

Version was selected above. We tried this bug on both linux and OSX. We tried chrome, safari and firefox and it only failed in firefox.
Other options are not related. The response was definitely from our api server once, but it was cached. It happened in two modes: POST and GET.
It's not cross-origin.

I don't know how to build a working example.

Our team think it's totally a cache problem. We speculate it happend in the following order:
1. User uses firefox to access our webapp's homepage for the first time and gets 400 `malformed authentication header` because there's no access_token.
2. The request contains a header cache: `force-cache but the response doesn't specify this should not be cached. So the response is cached by the browser.
3. Next time even when there's access_token, any request cached before would directly got blocked with this error by the browser. 
4. At the same time, wiredly, the request recorded in `network panel` has no `cache` header after this `cache process` by the browser.(This is why it costed us so much time to locate the bug in our own code).

We already fixed this bug from both front-end(remove cache header) and back-end(add no-cache header).
I report it here because there's a different behaviour here between firefox and other browsers. I'm not sure if this cache behaviour is a browser bug, but the missing cache header is definitely a bug.

Comment 5

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information