Open Bug 1338056 Opened 4 years ago Updated 2 years ago

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

Categories

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

51 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: sunfeng32, Unassigned)

Details

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`.
It seems
Summary: firefox checks the form of oauth request and return 400 Bad Request with `malformed authorization header` → firefox cached response but didn
Summary: firefox cached response but didn → firefox returns cached response but doesn't tell me that's a cached response
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Component: Networking: HTTP → DOM: Workers
I have tried it with Nightly and I do see 'cache' header. (but this can be a dup of 1273503).
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.
Component: DOM: Workers → DOM
Flags: needinfo?(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.
Component: DOM → Networking: Cache
Component: Networking: Cache → DOM
Flags: needinfo?(sunfeng32)
Priority: -- → P2
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
Priority: P2 → P3
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.