Solved: Apigee curl from trace does not match what is act... - Page 2

DanS · 08-12-2022 08:22 AM

I am trying to connect to Jira through apigee. During the trace I get a 405 method not allowed from the atlassian target server. So I looked for the curl of what was sent and it shows this:

curl -X POST -H 'Accept: 'application/json'' -H 'Accept-Encoding: gzip,deflate,br' -H 'Authorization: *****' -H 'Content-Type: application/json' -d '{"update":{},"fields":{"summary":"Test ticket","issuetype":{"id":"MYISSUETYPE"},"project":{"id":"MYPROJECTID"},"description":{"type":"doc","version":1,"content":[{"type":"paragraph","content":[{"text":"This is my description","type":"text"}]}]}}}' 'https://MYURLDOMAIN.atlassian.net/rest/api/3/issue'

I have redacted the private portions of the curl.

If I copy that curl request and replace the **** with the original auth that apigee is using it works fine and creates an issue in jira.

I pointed it at the apigee mock echo endpoint and it shows extra headers in the request that are not in that curl but added by apigee on the outbound trip. My assumption is that these additional headers are rejected by atlassian which is why it fails.

Has anyone successfully connected to jira through apigee and if so please tell me how. FWIW, I also tried doing this through a service callout and in javascript using the httpClient and nothing works.

dchiesa1

I see. Well that is inconvenient, isn't it?

I can see that it would be frustrating for one or more of these additional headers to cause the connection to be rejected. We're not certain, I guess, if it is the presence of one of those specific headers, or all of them, or some subset of them, that causes the auth to fail.

Unfortunately this behavior - injecting additional headers - comes from the Google network. It's just part of what happens with outbound connections. I don't believe it can be changed. As far as I know it is not possible.

Section 3.2.1 of IETF RFC 7230 , which defines HTTP, states that

   ...recipients SHOULD ignore unrecognized header fields.
   These requirements allow HTTP's functionality to be enhanced without
   requiring prior update of deployed intermediaries.

This is really just a restatement of the Robusness Principle. Applied to your case, we should conclude that Jira should benignly ignore the various "Extra" headers it is receiving in the request. It should be more tolerant of these common header fields.

If the problem is specifically and only the x-forwarded-for, I think it might be possible to configure Jira to ignore that specific header, or handle it differently. Check your jira documentation. (I'm not a jira expert) I'm not sure if the same can be done with those other headers.

View solution in original post

Apigee curl from trace does not match what is actually sent