Bug 179539 - Call willPerformHTTPRedirection on WebCoreNSURLSession's delegate
Summary: Call willPerformHTTPRedirection on WebCoreNSURLSession's delegate
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alex Christensen
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-11-10 12:00 PST by Alex Christensen
Modified: 2017-11-15 10:18 PST (History)
2 users (show)

See Also:


Attachments
Patch (8.41 KB, patch)
2017-11-10 12:04 PST, Alex Christensen
jer.noble: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Christensen 2017-11-10 12:00:24 PST
Call willPerformHTTPRedirection on WebCoreNSURLSession's delegate
Comment 1 Alex Christensen 2017-11-10 12:04:16 PST
Created attachment 326613 [details]
Patch
Comment 2 Jer Noble 2017-11-10 16:45:57 PST
Comment on attachment 326613 [details]
Patch

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

r=me, with nits.

> Source/WebCore/platform/network/cocoa/WebCoreNSURLSession.mm:617
> +    [self.session addDelegateOperation:[strongSelf = RetainPtr<WebCoreNSURLSessionDataTask>(self), response = RetainPtr<NSURLResponse>(response.nsURLResponse()), request = WTFMove(request), completionHandler = WTFMove(completionHandler)] () mutable {

Can't these "RetainPtr<...>(...)" calls just be "retainPtr(...)" calls?

> Source/WebCore/platform/network/cocoa/WebCoreNSURLSession.mm:619
> +        RetainPtr<NSURLRequest> nsRequest = request.nsURLRequest(DoNotUpdateHTTPBody);

auto?  Or maybe no need for this variable at all.

> Source/WebCore/platform/network/cocoa/WebCoreNSURLSession.mm:621
> +            [dataDelegate URLSession:(NSURLSession *)strongSelf.get().session task:(NSURLSessionTask *)strongSelf.get() willPerformHTTPRedirection:(NSHTTPURLResponse *)response.get() newRequest:nsRequest.get() completionHandler:BlockPtr<void(NSURLRequest *)>::fromCallable([completionHandler = WTFMove(completionHandler)](NSURLRequest *newRequest) mutable {

This is ... kinda ugly.  There should be some kind of templated "blockPtr()" which derives the BlockPtr template type from the signature of the callable, so that this could be written "completionHandler:blockPtr([...] { ... })";  Also, you're creating a block, wrapping it in a BlockPtr, just to call the completionHandler with the same signature as the BlockPtr and the block.  That's screaming for some simplification.

Also, why does response.get() have to be casted to a (NSHTTPURLResponse *)?  response is a RetainPtr<NSURLResponse>.
Comment 3 Alex Christensen 2017-11-13 14:59:17 PST
(In reply to Jer Noble from comment #2)
> This is ... kinda ugly.  There should be some kind of templated "blockPtr()"
> which derives the BlockPtr template type from the signature of the callable,
> so that this could be written "completionHandler:blockPtr([...] { ... })"; 
> Also, you're creating a block, wrapping it in a BlockPtr, just to call the
> completionHandler with the same signature as the BlockPtr and the block. 
> That's screaming for some simplification.
We do the same thing in our ObjC API.  I've made it two separate statements to be more clear.

> Also, why does response.get() have to be casted to a (NSHTTPURLResponse *)? 
> response is a RetainPtr<NSURLResponse>.
This API requires an NSHTTPURLResponse.  Not all NSURLResponses are NSHTTPURLResponses.  Ours should be, but I'll add an early return and an assert if it isn't.
Comment 4 Alex Christensen 2017-11-13 15:00:54 PST
http://trac.webkit.org/r224786
Comment 5 Radar WebKit Bug Importer 2017-11-15 09:44:23 PST
<rdar://problem/35562336>
Comment 6 Jer Noble 2017-11-15 10:18:18 PST
(In reply to Alex Christensen from comment #3)
> (In reply to Jer Noble from comment #2)
> > Also, why does response.get() have to be casted to a (NSHTTPURLResponse *)? 
> > response is a RetainPtr<NSURLResponse>.
> This API requires an NSHTTPURLResponse.  Not all NSURLResponses are
> NSHTTPURLResponses.  Ours should be, but I'll add an early return and an
> assert if it isn't.

Duh. Of course.