OAS API transformRequestHeaders available in OSS?

Product OAS
,
1

Is the transformRequestHeaders feature of the OAS api available in the OSS version? After using the Gateway API to import my OAS API I added the transformRequestHeaders section to the middleware.global:

"middleware": {
      "global": {
        "contextVariables": {
          "enabled": true
        },
        "trafficLogs": {
          "enabled": true
        },
        "transformRequestHeaders": {
          "enabled": true,
          "add": [
            {
              "name": "x-static",
              "value": "it worked!"
            },
            {
              "name": "x-jwt-sub",
              "value": "$tyk_context.jwt_claims_sub"
            },
            {
              "name": "x-jwt-aud",
              "value": "$tyk_context.jwt_claims_aud"
            }
          ]
        }
      },
      "operations": {
        "showHeaders": {
          "allow": {
            "enabled": true
          }
        },
        "test": {
          "allow": {
            "enabled": true
          }
        }
      }
    }

but when I send a request through the gateway none of the headers are being added to the request and as I use the Gateway API to pull the config of my OAS API the transformRequestHeaders section has been removed.

2

I dug in a bit further and it seems the issue may not be OSS vs commercial. Seems like the documentation for the OAS API object is incorrect and/or not yet implemented.

The OAS API schema references have no transformRequestHeaders object defined. If I include the transformRequestHeaders object in my OAS API json file in the /apps folder, start up the gateway, then pull the OAS API definition using the Gateway API, the transformRequestHeader object is stripped off.

It seems that in order to get the functionality of adding request headers as the request is proxied to the upstream the OAS API spec must have a Classic spec with the same api_id where the global_headers object can be used to define the headers that should be added:

"global_headers": {
    "x-came-from-tyk": "servicesverylongsecretthatnobodycanguess",
    "x-jwt-sub": "$tyk_context.jwt_claims_sub",
    "x-jwt-aud": "$tyk_context.jwt_claims_aud",
    "x-jwt-scp": "$tyk_context.jwt_claims_scp"
},
"global_headers_remove": [
    "authorization"
],
"global_headers_disabled": false

Is that correct, or am I missing something?

3

@elmaestro Welcome to the community and apologies for the late response

Yes, it is. You have to use the REST API to update the OAS spec which in turn updates the classic spec linked to the OAS spec. The opetation PUT /tyk/apis/oas/{apiID} should implement the change you want.

I can see what you mean. I am not sure where that value is being fetched from but I can see it’s the old definition before making the change on the filesystem. Maybe it’s cached somewhere. But it should be resolved once the current limitation of loading Tyk OAS APIs and Tyk Native APIs side by side is fixed

The transformRequestHeaders is implemented, you just have to use the REST API

I don’t think that spec is being used considering it hasn’t been updated in over 2 years. The gateway loads the classic API definitions and uses that to proxy the request. The Tyk OAS spec creates a classic API derivative of the same spec. Any changes to the OAS spec updates the classic spec accordingly. However, it looks like those changes can only be made via the REST API. You can submit a feature request if you want the OAS spec to act like the single source of truth during gateway startup or reload.

Yes, the OAS spec references a classic API definition through the info object like this:

"info": {
      "id": "4b92a2d7a5aa40c1b60948eba140e0bf",
      "name": "httpbin.org",
      "state": {
        "active": true
      }
    }

but you don’t need to deal with the classic API. Updating the OAS API through the /tyk/apis/oas endpoint should update the classic definition accordingly.

4

But if I am wanting to store the API definition files in git so that they can be pushed out on the filesystem of the containers then I need to have both the OAS and classic API definition files on the filesystem, correct?

5

Yes, that’s correct. You need to have both