Bug 226760 - Origin is null in http requests when baseURL has custom scheme on iOS 15.0
Summary: Origin is null in http requests when baseURL has custom scheme on iOS 15.0
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: Other
Hardware: iPhone / iPad Other
: P2 Critical
Assignee: Alex Christensen
URL:
Keywords: InRadar
: 226769 (view as bug list)
Depends on: 227560
Blocks:
  Show dependency tree / graph
 
Reported: 2021-06-08 01:20 PDT by zhuoran1997
Modified: 2021-07-14 12:25 PDT (History)
6 users (show)

See Also:

Attachments
A demo project and results of iOS 14.5 and iOS 15.0 (130.17 KB, application/zip)
2021-06-08 01:20 PDT, zhuoran1997 		no flags Details
Patch (6.74 KB, patch)
2021-06-09 21:43 PDT, Alex Christensen 		no flags Details | Formatted Diff | Diff
Patch (6.48 KB, patch)
2021-06-09 23:16 PDT, Alex Christensen 		no flags Details | Formatted Diff | Diff
Patch (6.75 KB, patch)
2021-06-10 08:56 PDT, Alex Christensen 		ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description zhuoran1997 2021-06-08 01:20:05 PDT 
Created attachment 430817 [details]
A demo project and results of iOS 14.5 and iOS 15.0

There is a regression in WKWebView on iOS 15.0. When setting the baseURL of the WKWebView to `custom-scheme://` via webView.loadHTMLString(, baseURL:), the Origin in http request header becomes `null` instead of `custom-sheme://` on iOS 15.0. iOS 14.6 doesn't have this issue.

I have attached a demo project. You can run it with Xcode 12.5 and Xcode 13.0 to see the difference. After attaching inspector, press the "Request data" button. Then you can see the different Origin value in network request.
Comment 1 Radar WebKit Bug Importer 2021-06-08 12:22:40 PDT 
<rdar://problem/79027280>
Comment 2 Alex Christensen 2021-06-09 21:43:13 PDT 
Created attachment 431049 [details]
Patch
Comment 3 Chris Dumez 2021-06-09 21:50:23 PDT 
Comment on attachment 431049 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=431049&action=review

> Source/WebCore/page/SecurityOrigin.h:280
> +    origin->m_data = WTFMove(*data);

I have read your change log twice and I still don’t understand this change. It looks suspicious to set the securityorigindata (which is protocol / host / port) right after constructing a security origin with those same protocol / host / port.
Comment 4 Chris Dumez 2021-06-09 22:11:45 PDT 
Comment on attachment 431049 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=431049&action=review

R=me with the change

>> Source/WebCore/page/SecurityOrigin.h:280
>> +    origin->m_data = WTFMove(*data);
> 
> I have read your change log twice and I still don’t understand this change. It looks suspicious to set the securityorigindata (which is protocol / host / port) right after constructing a security origin with those same protocol / host / port.

I looked at the create() function and it looks like it constructs a url from the components, only to then later on extract the components from the URL :( this is a bit unfortunate. I think your change would probably look better if you did:
auto origin = adoptRef(*new SecurityOrigin);
origin->m_data = WTFMove(*data);

It would also be more efficient.
Comment 5 Alex Christensen 2021-06-09 23:16:56 PDT 
Created attachment 431051 [details]
Patch
Comment 6 Alex Christensen 2021-06-10 08:56:26 PDT 
Created attachment 431084 [details]
Patch
Comment 7 Alex Christensen 2021-06-10 16:26:12 PDT 
r278737
Comment 8 Alex Christensen 2021-06-10 16:26:33 PDT 
Thanks for reporting this bug!
Comment 9 Alex Christensen 2021-06-11 17:23:32 PDT 
*** Bug 226769 has been marked as a duplicate of this bug. ***
Comment 10 Niklas Merz 2021-07-01 23:35:07 PDT 
Looks like the latest Developer Beta 2 (19A5281j) brought this issue back. I got CORS issues (failed preflight request) again.

> Failed to load resource: Preflight response is not successful