HTTP method changed in IS after receiving HTTP 301 Redirect

,
#1

Hi,

We are consuming a REST API from Salesforce and made a HTTP PATCH call from the Integration Server to Salesforce.
However, we observed that Salesforce received a GET request instead of PATCH. On increasing the logging level within IS, we observed that Salesforce initially sent back a HTTP 301 status code and following redirection, the method got changed to GET while making the call to the new URL.

I read on one of the knowledge center articles that this has been handled in IS version 10.0 and up but we are using 10.3 and facing this issue. Does anybody have a solution or workaround for this?

Thanks

#2

try:

  1. use https instead
  2. use the “Location” header response of 301 as your target url
#3

Might this be due to SFDC using the P-R-G technique? P is usually POST but could also be PATCH. It is typically for UIs to avoid users hitting the back button and submitting the same data again but can be useful for APIs too – PATCH is processed, Redirect returned to reference URL affected by the patch, GET to get the latest data which was just changed by the patch.

To confirm that is the behavior, should see the PATCH and a GET in Salesforce log.

Thought this might be something to consider as an alternative explanation.

#4

If the service being used here is pub.client:http, IS automatically follows. No way to handle that yourself. Indeed, appears no way to prevent pub.client:http from following redirects, which is something of a bummer in some cases.

#5

Thanks for the reply reamon. We already checked it with Salesforce but this is not the case. The record has not been updated and they cannot see any PATCH requests come through.

Moreover, the same call works perfectly fine through Postman which means it is handling the redirect gracefully.

Looks like the Integration Server does not handle all redirect related HTTP response codes contrary to what is mentioned in the knowledge center on empower.

#6

Hi Vaibhav,

If you’re sure that IS is not handling it as per what it’s expected to do, I’ll suggest you to come out with a sample package and save the pipeline to demonstrate your observation. If the R&D from SAG is able to reproduce and confirm the same behavior after you’ve submitting an official case to them with the package, I’m sure they’ll be able to provide you some sort on fix on it.

#7

What was it responding to if not the PATCH?