Library does not respond to status code 302 as desired

[digitalergonom]

When PATCHing to a RESTful service, the service responds with 302 to redirect me to the updated source. Instead getting it's content (default RoR behavior) the library retries to PATCH to the new url, which ends in an infinite loop, which is only catched by my servers spam protection.

I tried to intercept this by overwriting _performApiCall and looking at fail and done. Both methods are not called, until my server stops the cycle by sending a status code of 0.

My suggestion is, to keep the current implemtation as default behavior, but enable the interception by (a) a concrete method or (b) a new entry in ApiCallOptions.

Looking forward to discuss a possible solution, that does not include changing the backend.

Regards,
Sascha

[deregtd]

What platform is this on? On browsers, the browser does the 302 follow behavior without ever calling back into the library to let us alter the behavior. On Skype, the service had to actually add a browser mode to not return 302 but instead return a 404 with a location header, so that web clients could manually record a redirect to the proper location and update api bases/etc.

[digitalergonom]

Hi @deregtd,

thanks for your fast response. We are developing an application with ReactXP, that runs in an Electron-environment. So we are using the web-output of RXP in chromium to also support Unix-platforms.

Regards,
Sascha

[deregtd]

Chromium should have the same general browser behavior. I don't believe there's anything we can do here, unfortunately. If you step through the code and you find that there's handling we can add for this, I'd be happy to add it to the library.