Add a block to handle redirects #265

Closed
kcharwood opened this Issue Mar 22, 2012 · 14 comments

Projects

None yet

4 participants

@kcharwood
Contributor

Referencing #120...

I ran into an issue today where I hit an API that did a redirect to another URL within the API. Digger deeper in NSURLConnection, it looks like by default the redirected URL doesnt carry along the same headers the original request had. In my case, auth was failing with the redirected URL.

I solved the problem by subclassing AFJSONRequestOperation and overriding -connection:willSendRequest:redirectResponse: to handle my special case, but it would be nice to have a block to handle the callback on a per operation basis without requiring a subclass.

Haven't had the time to fork and update yet, so opening this up to see if anyone else gets a chance to get to it before I circle back around.

@kevinbarrett

I ran into the same problem but I'm unsure of how to override -connection:willSendRequest:redirectResponse: for both iOS 4.3 and iOS 5.x. This would fix it nicely.

@kevinbarrett

Ignore the "unsure" part of the last comment. Still would be nice, though :)

@kcharwood
Contributor

@kevinbarrett - To override the behavior, make a subclass of the operation you are using (in my case it was AFJSONRequestOperation), and override the method as shown below:

- (NSURLRequest *)connection: (NSURLConnection *)inConnection
             willSendRequest: (NSURLRequest *)inRequest
            redirectResponse: (NSURLResponse *)inRedirectResponse
{
    if (inRedirectResponse) {
       //Create your mutable request to return in the redirect scenario
    } else {
        return inRequest;
}
@kevinbarrett

@kcharwood Thanks, I figured it out yesterday, didn't realize the method was part of an informal protocol and went hunting for the docs.

@kcharwood
Contributor

Added a block in commit c050092

@mattt - take a look and let me know if you have any feedback.

@kcharwood
Contributor

Realized I screwed up the naming convention of the blocks. Fixed in ca82a4b

@mattt
Contributor
mattt commented Mar 25, 2012

@kcharwood Looks reasonable to me. I'll take a closer look in the next day or two and give you some actual feedback. Thanks!

@kcharwood
Contributor

Hey @mattt... Any plans to bring this in?

@mattt
Contributor
mattt commented May 22, 2012

I've been hesitant to bring it in for fear of users needlessly using it in their code base, since it is pretty rare that this is needed.

Also, by adding it, we'd be at the point that so many NSURLConnection delegate methods are implemented, that it would be confusing if all of them weren't (or maybe we're already at this point).

All of that said, sure—let's get this in there. I'd happily accept a pull request or re-implement this myself.

@jj0b
jj0b commented May 24, 2012

@matt any more thoughts on putting this into master?

@mattt
Contributor
mattt commented May 24, 2012

@jj0b Per my previous response, I'm just waiting for the pull request.

@jj0b
jj0b commented May 24, 2012

@kcharwood I see you had a pull request for this but closed it. Are you planning to open it again?

@kcharwood
Contributor

I made a pull request a while back ago on the wrong branch. Busy day today before I head out on vacation for the next 4-5 days, but I may get to it today before I leave.

@kcharwood
Contributor

Check out #344

@kcharwood kcharwood closed this May 24, 2012
@ale0xb ale0xb referenced this issue in ParsePlatform/ParseUI-iOS Sep 5, 2015
Closed

ParseUI won't compile for application extensions #144

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment