Bug 239944 - Safari does not persist the Authorization header on redirect
Summary: Safari does not persist the Authorization header on redirect
Status: RESOLVED DUPLICATE of bug 230935
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-05-01 08:29 PDT by lmx
Modified: 2024-07-12 01:34 PDT (History)
9 users (show)

See Also:


Attachments
Example (2.92 KB, patch)
2022-05-16 08:04 PDT, youenn fablet
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description lmx 2022-05-01 08:29:21 PDT
Sorry, my English is not good, the following content is generated by translation software.

I describe the problem I have:

In Safari, I send a request via fetch:

/api/user/list?page=1&page_size=10

Because the path is wrong, the status code returned by the server is 301, and a new request path is given:

/api/user/list/?page=1&page_size=10

After Safari receives 301, it automatically sends a new request, but does not bring the Authorization request header.

My expectation is to bring the Authorization request header when redirecting, what should I do? Looking forward to your reply, thanks.

Note: When redirecting, the Chrome browser will take the Authorization request with it.

The full request log is below:

First request(Has Authorization request header):

Request
GET /api/user/list?page=1&page_size=10
Authorization: Bearer xxxxxxxxxxxx
Referer: https://test.com/api/user/list?page=1&page_size=10
Accept: */*
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Safari/605.1.15
Cache-Control: no-cache
Pragma: no-cache
X-OA-ID: 10004572

------

Response to first request:

Redirect Response
301 Moved Permanently
Location: /api/user/list/?page=1&page_size=10
Date: Sun, 01 May 2022 09:29:24 GMT
Referrer-Policy: same-origin

------

Redirects automatically sent by Safari(No Authorization header):

Request
GET /api/user/list/?page=1&page_size=10 HTTP/1.1
Accept: */*
Pragma: no-cache
Cookie: xxxxxxxxxxxx
Referer: https://test.com/api/user/list
Cache-Control: no-cache
Host: test.com
Accept-Language: en-US,en;q=0.9
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Safari/605.1.15
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
X-OA-ID: 10004572

------


I found 2 similar questions on stackoverflow, but none were solved.

https://stackoverflow.com/questions/71311305/how-to-prevent-safari-from-dropping-the-authorization-header-when-following-a-sa

https://stackoverflow.com/questions/57974176/safari-does-not-persist-the-authorization-header-on-redirect
Comment 1 youenn fablet 2022-05-04 02:26:43 PDT
It seems to make sense to keep the authorization header for same origin redirections.
It would be good to check where we are dropping the header (WebKit networking code or CFNetwork).

See https://github.com/whatwg/fetch/issues/944 for WhatWG fetch discussion.
Comment 2 Radar WebKit Bug Importer 2022-05-04 02:26:54 PDT
<rdar://problem/92721299>
Comment 3 youenn fablet 2022-05-16 08:04:43 PDT
Created attachment 459426 [details]
Example
Comment 4 youenn fablet 2022-05-16 08:06:37 PDT
I uploaded an example which seems to show that the Authorisation header is being preserved on same origin redirections.

@lmx, on which Safari version are you? Can you try Safari Tech Preview?
Can you provide a repro case (public or privately at youenn@apple.com) or look at the provided example to see what is different?
Comment 5 lmx 2022-05-17 07:01:31 PDT
@youenn fablet

Hello, I uploaded the code here.
https://github.com/mrlmx/safari-redirect-demo


You can also test through this online demo.
https://safari-redirect-demo.vercel.app
Comment 6 youenn fablet 2022-05-17 07:45:04 PDT
Testing in Safari Tech Preview on macOS Monterey, I get the list of users with https://github.com/mrlmx/safari-redirect-demo:
lmx:18
foo:17
bar:16

@lmx, which version of Safari and iOS/macOS are you testing on?
Comment 7 lmx 2022-05-17 07:53:02 PDT
@youenn fablet

Neither of my two Macs works properly. This is the corresponding version.

---

macOS Monterey
Version 12.1 (21C52)

Safari
Version 15.2 (17612.3.6.1.6)

---

macOS Big Sur
Version 11.3(20E232)

Safari
Version 14.1 (16611.1.21.161.3)
Comment 8 youenn fablet 2022-05-17 22:56:27 PDT
This is now fixed in latest Safari macOS 12.3

*** This bug has been marked as a duplicate of bug 230935 ***
Comment 9 lmx 2022-05-17 23:42:01 PDT
Thank you(In reply to youenn fablet from comment #8)
> This is now fixed in latest Safari macOS 12.3
> 
> *** This bug has been marked as a duplicate of bug 230935 ***
Comment 10 derben 2023-09-29 12:10:16 PDT
I’m still experiencing this issue on Safari for iOS on my IPhone SE 2020 running iOS 16.6.1. Shouldn’t this be fixed?
Comment 11 Alexey Proskuryakov 2023-09-29 12:34:13 PDT
Yes, it's supposed to have been fixed. Could you please file a new bug from scratch, with precise steps to reproduce and any additional information?