[Webkit-unassigned] [Bug 247418] New: Safari reuses Authorization header on second call to 301 redirects even if the header value changed when replaying the request
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Nov 3 04:00:43 PDT 2022
https://bugs.webkit.org/show_bug.cgi?id=247418
Bug ID: 247418
Summary: Safari reuses Authorization header on second call to
301 redirects even if the header value changed when
replaying the request
Product: WebKit
Version: Safari 16
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: Page Loading
Assignee: webkit-unassigned at lists.webkit.org
Reporter: info+webkit at ssaavedra.eu
CC: beidson at apple.com
We have a server that redirects non-canonical API calls to their canonical counterpart using 301 Moved Permanently redirects.
This bug can be replicated using fetch(), with any non-canonical API call (e.g., /api/users instead of /api/users/).
If we start with a clear cache, everything works. However, if we log in onto the web app (i.e., generate a new token), perform the API call, then log out (invalidating the token on the server side) and back in again, now the API call will fail with a 401 since the token used will be the old one that has been invalidated.
The first request will use the correct Authorization header, but after the server sends the 301 redirect response, Safari will use the old Authorization header for the next request to the /api/users/ call, (which uses a token that has already been invalidated).
This is not happening on Chrome or Firefox on macOS or Windows, but is happening on Safari 16.1 for macOS and on iOS 16.0.3.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20221103/d6c257f6/attachment-0001.htm>
More information about the webkit-unassigned
mailing list