[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