Bug 225596 - Preflight requests not properly attributed as app-bound
Summary: Preflight requests not properly attributed as app-bound
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Kate Cheney
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-05-10 08:20 PDT by Kate Cheney
Modified: 2021-05-10 15:41 PDT (History)
5 users (show)

See Also:


Attachments
Patch (20.83 KB, patch)
2021-05-10 08:42 PDT, Kate Cheney
no flags Details | Formatted Diff | Diff
Patch (21.80 KB, patch)
2021-05-10 11:51 PDT, Kate Cheney
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kate Cheney 2021-05-10 08:20:42 PDT
Preflight requests are not properly attributed as app-bound.
Comment 1 Kate Cheney 2021-05-10 08:21:22 PDT
<rdar://problem/77664272>
Comment 2 Kate Cheney 2021-05-10 08:42:30 PDT
Created attachment 428173 [details]
Patch
Comment 3 Alex Christensen 2021-05-10 09:18:31 PDT
Comment on attachment 428173 [details]
Patch

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

> Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h:410
> +- (void)_appBoundLoadData:(BOOL)isRequestingLoadsMarkedAppBound completionHandler:(void (^)(BOOL result))completionHandler WK_API_AVAILABLE(macos(WK_MAC_TBA), ios(WK_IOS_TBA));

This should be two functions instead of one function with a bool indicating which function it is calling.
Comment 4 Brent Fulgham 2021-05-10 11:00:01 PDT
Comment on attachment 428173 [details]
Patch

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

> Source/WebCore/loader/CrossOriginAccessControl.cpp:92
> +    preflightRequest.setIsAppBound(request.isAppBound());

I worry that other flags in the request might be missed if we rely on manually copying them over. We should take this action today, but I think we should consider a more general way to spawn a preflight request from an existing request to retain relevant state.

>> Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h:410
>> +- (void)_appBoundLoadData:(BOOL)isRequestingLoadsMarkedAppBound completionHandler:(void (^)(BOOL result))completionHandler WK_API_AVAILABLE(macos(WK_MAC_TBA), ios(WK_IOS_TBA));
> 
> This should be two functions instead of one function with a bool indicating which function it is calling.

Do we need to add a separate method if these are purely for testing purposes? Passing a parameter means we could parameterize the test so the same code could be used for both flavors of test.
Comment 5 Kate Cheney 2021-05-10 11:07:10 PDT
(In reply to Brent Fulgham from comment #4)
> Comment on attachment 428173 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=428173&action=review
> 
> > Source/WebCore/loader/CrossOriginAccessControl.cpp:92
> > +    preflightRequest.setIsAppBound(request.isAppBound());
> 
> I worry that other flags in the request might be missed if we rely on
> manually copying them over. We should take this action today, but I think we
> should consider a more general way to spawn a preflight request from an
> existing request to retain relevant state.

Good point, I'm not exactly sure what state matters here. Marking app-bound requests is important for all network connections, but it's possible that other state isn't important for special requests like preflight checks that just check the CORS policy.

> 
> >> Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h:410
> >> +- (void)_appBoundLoadData:(BOOL)isRequestingLoadsMarkedAppBound completionHandler:(void (^)(BOOL result))completionHandler WK_API_AVAILABLE(macos(WK_MAC_TBA), ios(WK_IOS_TBA));
> > 
> > This should be two functions instead of one function with a bool indicating which function it is calling.
> 
> Do we need to add a separate method if these are purely for testing
> purposes? Passing a parameter means we could parameterize the test so the
> same code could be used for both flavors of test.

I see Alex's point, the test function reads weirdly with a boolean. I'm not opposed to splitting it up, but it's unfortunate that it adds so much more boilerplate WebKitTestRunner code.
Comment 6 Kate Cheney 2021-05-10 11:51:43 PDT
Created attachment 428190 [details]
Patch
Comment 7 Brent Fulgham 2021-05-10 15:26:06 PDT
Comment on attachment 428190 [details]
Patch

Looks good. r=me
Comment 8 EWS 2021-05-10 15:41:38 PDT
Committed r277301 (237562@main): <https://commits.webkit.org/237562@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 428190 [details].