provider/aws: aws_api_gateway_method_response headers?

[ijin]

Are setting response headers implemented yet?

I need to set headers like Access-Control-Allow-Origin to my responses in API GW.

[stack72]

Hi @ijin

This hasn't been implemented yet. I just found the following in the code:

func resourceAwsApiGatewayIntegrationResponseCreate(d *schema.ResourceData, meta interface{}) error {
    conn := meta.(*AWSClient).apigateway

    templates := make(map[string]string)
    for k, v := range d.Get("response_templates").(map[string]interface{}) {
        templates[k] = v.(string)
    }

    _, err := conn.PutIntegrationResponse(&apigateway.PutIntegrationResponseInput{
        HttpMethod:        aws.String(d.Get("http_method").(string)),
        ResourceId:        aws.String(d.Get("resource_id").(string)),
        RestApiId:         aws.String(d.Get("rest_api_id").(string)),
        StatusCode:        aws.String(d.Get("status_code").(string)),
        ResponseTemplates: aws.StringMap(templates),
        // TODO implement once [GH-2143](https://github.com/hashicorp/terraform/issues/2143) has been implemented
        ResponseParameters: nil,
    })
    if err != nil {
        return fmt.Errorf("Error creating API Gateway Integration Response: %s", err)
    }

    d.SetId(fmt.Sprintf("agir-%s-%s-%s-%s", d.Get("rest_api_id").(string), d.Get("resource_id").(string), d.Get("http_method").(string), d.Get("status_code").(string)))
    log.Printf("[DEBUG] API Gateway Integration Response ID: %s", d.Id())

    return nil
}

Notice the comment there above RequestParameters

Thanks

Paul

[ijin]

oh, thanks. looks like it's going to take a while..

#2143

[joshrtay]

is there any reason this can't be implemented before fixing #2143? i assume this would work with JSON syntax and it's critical for us.

[joshrtay]

Another options here is to expose a different API:

It looks like AWS sdk go expects the following for response paramaters:

{
   "integration.response.body.type/Content-Type": true
}

While aws sdk node expects:

{
  "Content-Type": "integration.response.body.type"
}

If terraform exposed an api that looked more like nodes, would we be in the clear?

resource "aws_api_gateway_integration_response" "test" {
  rest_api_id = "${aws_api_gateway_rest_api.test.id}"
  resource_id = "${aws_api_gateway_resource.test.id}"
  http_method = "${aws_api_gateway_method.test.http_method}"
  status_code = "${aws_api_gateway_method_response.error.status_code}"

  response_paramaters = {
    "Content-Type" = "integration.response.body.type"
  }

  response_templates = {
    "application/json" = ""
    "application/xml" = "#set($inputRoot = $input.path('$'))\n{ }"
  }
}

[joshrtay]

Welp forget that. Just realized I mixed-up the types for integration response and method response parameters.

[joshrtay]

I think the observation stands though. We can change up the terraform api so that there are no dots in keys.

method response response parameters could look like:

response_parameters = {
  "Content-Type" = true
}

and integration response could look like:

response_paramaters = {
    "Content-Type" = "integration.response.body.type"
  }

Then the provider can change the keys to be of the form integration.response.header.{name}

[joshrtay]

Then, assuming I have the prefix right, the code becomes:

func resourceAwsApiGatewayIntegrationResponseCreate(d *schema.ResourceData, meta interface{}) error {
    conn := meta.(*AWSClient).apigateway

    templates := make(map[string]string)
    for k, v := range d.Get("response_templates").(map[string]interface{}) {
        templates[k] = v.(string)
    }

    paramaters := make(map[string]string)
    for k, v := range d.Get("response_paramaters").(map[string]interface{}) {
        paramaters["integration.response.header." + k] = v.(string)
    }

    _, err := conn.PutIntegrationResponse(&apigateway.PutIntegrationResponseInput{
        HttpMethod:        aws.String(d.Get("http_method").(string)),
        ResourceId:        aws.String(d.Get("resource_id").(string)),
        RestApiId:         aws.String(d.Get("rest_api_id").(string)),
        StatusCode:        aws.String(d.Get("status_code").(string)),
        ResponseTemplates: aws.StringMap(templates),
        ResponseParameters: aws.StringMap(paramaters),
    })
    if err != nil {
        return fmt.Errorf("Error creating API Gateway Integration Response: %s", err)
    }

    d.SetId(fmt.Sprintf("agir-%s-%s-%s-%s", d.Get("rest_api_id").(string), d.Get("resource_id").(string), d.Get("http_method").(string), d.Get("status_code").(string)))
    log.Printf("[DEBUG] API Gateway Integration Response ID: %s", d.Id())

    return nil
}

[joshrtay]

@radeksimko would love to get your thoughts on changing the api to avoid #2143

[radeksimko]

@joshrtay While I totally understand the need to get this implemented with or without #2143 I'm not entirely sure about this approach.

If we're really going to implement this without #2143 I believe there should be an easy way to migrate users to the correct DSL once #2143 is fixed.

I was thinking along the lines of raw JSON, e.g.

response_paramaters_in_json = <<PARAMS
{
   "integration.response.body.type/Content-Type": true
}
PARAMS

it may not look as nice and natural, but it respects the API/SDK and provides a fairly clean migration path to a state when #2143 is fixed - e.g. we can mark response_paramaters_in_json deprecated and introduce response_paramaters, or we might even keep both there for a while and have common logic processing these as the only difference would be json-marshalled string or unmarshalled object.

Also the field name suggests what is expected from the user (_in_json).

What do you think?

[joshrtay]

That works for me.

When using JSON syntax I assume you'd still have to use the response_parameters_in_json field name and it would look something like?

"response_parameters_in_json": "{ \"integration.response.body.type/Content-Type\": true }"

[radeksimko]

If you (for any reason) didn't want to use the HEREDOC syntax I presented in the example above, then yes, it would look exactly like that - including the backslashes.

We could also use normalizeJson helper we use elsewhere to ensure that no diffs/updates are generated for whitespace/newline changes.

[joshrtay]

Ok got it. I'd love to get this in master by the end of the week. If it would speed things up, I'd be happy to submit a pull request. Though I have zero go experience.

[joshrtay]

@radeksimko Took a stab at it. #6344

[radeksimko]

#6344 merged, it will be available in the next release 0.6.16 as response_parameters_in_json for both aws_api_gateway_integration_response and aws_api_gateway_method_response.

It may be reimplemented in the future once as discussed above, but I'm closing this issue for now.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.