Moya: Don't follow redirects

Created on 26 Nov 2018  Â·  9Comments  Â·  Source: Moya/Moya

Description

We're looking for a way to not follow redirects on some targets.

Is there a way to handle redirects individually?

We're using the latest Moya version. From our Podfile.lock:

- Moya/Core (12.0.1):
  - Alamofire (~> 4.1)
  - Result (~> 4.0)
question

Most helpful comment

Thank you for explaining, my apologies on not understanding that context.

To keep Moya simple, my initial opinion is to mark that as wontfix, and say the mitigation is to use a different Provider for each TargetType.

Thanks for taking care of this @SD10

All 9 comments

@xavierLowmiller Hey, this might be configurable through Alamofire's manager.

Can you check out this stack overflow post on handling redirects in Alamofire -- it links to a related PR for support for this in Alamofire

We're looking for a way to not follow redirects on some targets.

If your question is specifically asking about how to configure this on a target by target basis, I don't have any great ideas off the top of my head. The Alamofire Manager used by a MoyaProvider can only be configured per provider:

https://github.com/Moya/Moya/blob/master/Sources/Moya/MoyaProvider%2BDefaults.swift#L28-L37

Without giving this more thought, I'd say you may need two providers -- one that allows redirects and one that does not.

Thanks for answering this!

We ended up setting the taskWillPerformHTTPRedirection closure on MoyaProvider.manager.delegate that conditionally follows redirects based on the URL's path.

What I was hoping for would be a shouldFollowRedirect or something as an extension on TargetType, similar to the optional validationType.

I'm willing to look into this. Would you be interested in a Pull Request?

What I was hoping for would be a shouldFollowRedirect or something as an extension on TargetType, similar to the optional validationType.

I'm willing to look into this. Would you be interested in a Pull Request?

@xavierLowmiller My concern is that TargetType will become bloated with all of these configurations. We have a policy of not setting default values for protocol requirements in order to be explicit in the intent.

I'm also concerned about how this would work with concurrent requests that all share the same Manager 🤔

Will tag @Moya/contributors to see if anyone has input or more experience here

It might also fall under the „common things are easy, and uncommon things are possible“ category.
I’ve been using Moya for over a year in various projects, and this is the first time I’m running into this.

The thing I don’t like about our current implementation is that the decision to follow redirects is now completely independent of any TargetType, so I thought it might make sense to somehow combine this.

I feel as if the right answer here would be passing in a custom Alamofire Manager into Moya, we already support that, right? That way you can set all the options you care about for Alamofire, and pass the configured manager to Moya to use

Yep @AndrewSB, that I agree with. He's looking to customize the behavior of MoyaProvider's manager on a TargetType by TargetType basis. Not sure if that is feasible, or as he mentioned, common enough to support in Moya

Thank you for explaining, my apologies on not understanding that context.

To keep Moya simple, my initial opinion is to mark that as wontfix, and say the mitigation is to use a different Provider for each TargetType.

Thanks for taking care of this @SD10

It might also fall under the „common things are easy, and uncommon things are possible“ category.
I’ve been using Moya for over a year in various projects, and this is the first time I’m running into this.

I totally agree this falls under that statement. It doesn't seem to be a scenario that is common enough to make it to the TargetType. In fact, this seems to be first issue created for this topic.

The thing I don’t like about our current implementation is that the decision to follow redirects is now completely independent of any TargetType, so I thought it might make sense to somehow combine this.

Totally agree with you, but I still feel this is a very specific scenario and maybe it's not worth to implement it on TargetType. If we start getting more request from people trying to avoid following redirects based on TargetType then I think it would make sense to work on it.

I think we're on the same page here. Let's close this.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

fenixsolorzano picture fenixsolorzano  Â·  3Comments

JoeFerrucci picture JoeFerrucci  Â·  3Comments

cocoatoucher picture cocoatoucher  Â·  3Comments

hamada147 picture hamada147  Â·  3Comments

fenixsolorzano picture fenixsolorzano  Â·  3Comments