I'm in Amazon's API Gateway, and any change to the Mapping Templates section of the Integration Response breaks the Resource/Method (causes the Test to return an error) and cannot be fixed (you must delete the Resource/Method and create a new one).
I create a new Resource, then create a new Method (POST) under that.
I map this to a simple Lambda function (it doesn't require any parameters and only returns/logs 'hi').
I test this, and it succeeds.
I go into Integration Response, and I change the Mapping Templates ... I change application/json to application/xml and I change 'Output passthrough' to 'Mapping template'.
I enter this as the template:
#set($inputRoot = $input.path('$'))
<?xml version="1.0" encoding="UTF-8"?>
<Response>
<Message>
<Body>
$inputRoot
</Body>
</Message>
</Response>
I save that by clicking the checkbox and by clicking the Save button.
I go back to test it
This is the result:
{
"message": "Internal server error"
}
This is the content of the Logs output (I replaced potentially sensitive information with [explanation here] since I'm not sure what's sensitive or not):
Execution log for request test-request
Sun Dec 06 17:33:50 UTC 2015 : Starting execution for request: test-invoke-request
Sun Dec 06 17:33:50 UTC 2015 : API Key: test-invoke-api-key
Sun Dec 06 17:33:50 UTC 2015 : Method request path: {}
Sun Dec 06 17:33:50 UTC 2015 : Method request query string: {}
Sun Dec 06 17:33:50 UTC 2015 : Method request headers: {}
Sun Dec 06 17:33:50 UTC 2015 : Method request body before transformations: null
Sun Dec 06 17:33:50 UTC 2015 : Endpoint request URI: [lambda uri here]
Sun Dec 06 17:33:50 UTC 2015 : Endpoint request headers: {Authorization=[lots of * here], X-Amz-Date=20151206T173350Z, X-Amz-Source-Arn=[arn here], Accept=application/json, User-Agent=AmazonAPIGateway_[string here], Host=lambda.us-east-1.amazonaws.com}
Sun Dec 06 17:33:50 UTC 2015 : Endpoint request body after transformations:
Sun Dec 06 17:33:50 UTC 2015 : Endpoint response body before transformations: "hi"
Sun Dec 06 17:33:50 UTC 2015 : Endpoint response headers: {x-amzn-Remapped-Content-Length=0, x-amzn-RequestId=[data here], Connection=keep-alive, Content-Length=12, Date=Sun, 06 Dec 2015 17:33:50 GMT, Content-Type=application/json}
Sun Dec 06 17:33:50 UTC 2015 : Execution failed due to configuration error: No match for output mapping and no default output mapping configured
Sun Dec 06 17:33:50 UTC 2015 : Method completed with status: 500
I also tried going into Method Response, and changing the Content Type for Response Models for 200 from application/json to application/xml ... That produced the same error.
I also tried, at this point, to revert my changes ... Method Response back to application/json & Integration Response back to application/json and 'Output passthrough' ... That produced the same error - it's like this API Resource/Method is now permanently broken.
I also tested another new Resource, changing only the Content Type for Response Models for 200 in Method Response from 'application/json' to 'application/xml' ... This resulted in a successful test.
I also tried a more minor change to the Mapping Templates in Integration Response ... Rather than a full switch from 'Output passthrough' to 'Mapping Template', I just changed the content type from application/json to application/xml ... This resulted in the same error.
So it seems like the root cause is changing from Output Passthrough to Mapping Template ... Once that change is made, the test will fail & you will not be able to return it to a passing state - you must delete the Resource/Method entirely & start a new one.
Also, to be clear, there are no deploys throughout any of this process - I'm strictly working in the AWS console itself, using their 'Test' link in the web interface.
Anyone know what's going on here?
I'm also trying to get an answer in their Discussion Forum, but those threads usually aren't nearly as active as here...
Added Note
I do have a functional deploy running, which uses this mapping template. That deploy is from 18:35 12-05-2015, so it's possible that this is a new error/change in the Amazon API Gateway...
This must have been a temporary issue with API Gateway, because the issue is gone now.
There's one caveat:
NEVER click the big Save button on the Integration Response page. That seems to cause issues, at least as of today (2015-12-05).
I spoke with amazon's support staff and its a known issue. As long as you don't press the Save button you should be fine but once you do there is no going back.
Just press the checkbox thing when making changes to the template and refresh the page. That seems to work for me.
There was an issue with APIs when saving the default integration response mapping. The bug caused requests to your API methods that were saved incorrectly to return a 500 error, the CloudWatch logs should say "Execution failed due to configuration error: No match for output mapping and no default output mapping configured".
The issue is now resolved. If you are experiencing this, please re-deploy your API configuration.
For more information, please refer to this AWS forums entry: https://forums.aws.amazon.com/thread.jspa?threadID=221197&tstart=0
Regards,
Jurgen
The issue is now resolved. It's now safe to save the default integration response. If your deployed APIs are having issues, a redeploy should resolve the problem. Thanks for your patience.
Ryan
Related
I'm sending a Link preload header in the HTTP2 response. Like this one:
Link: </assets/script/main.js?h=1795387974>; rel=preload; as=script, </assets/font/sourcesanspro_regular.woff2>; rel=preload; as=font
scripts, styles and images don't cause any problem - they are pushed and used. But fonts are pushed and then requested/fetched again and the Chromium console complains:
The resource https://example.com/assets/font/sourcesanspro_regular.woff2 was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it wasn't preloaded for nothing.
Here are the response headers of the mentioned font.
Pushed:
accept-ranges:bytes
cache-control:max-age=5184000, public
content-length:16892
content-type:application/octet-stream
date:Mon, 25 Sep 2017 09:22:05 GMT
last-modified:Mon, 18 Sep 2017 14:33:31 GMT
pragma:public
status:200
x-content-type-options:nosniff
x-frame-options:SAMEORIGIN
x-http2-push:pushed
x-xss-protection:1; mode=block
Requested after push:
accept-ranges:bytes
cache-control:max-age=5184000, public
content-length:16892
content-type:application/octet-stream
date:Mon, 25 Sep 2017 09:22:05 GMT
last-modified:Mon, 18 Sep 2017 14:33:31 GMT
pragma:public
status:200
x-content-type-options:nosniff
x-frame-options:SAMEORIGIN
x-xss-protection:1; mode=block
What am I doing wrong?
You have to add crossorigin for fonts:
Link: </assets/font/sourcesanspro_regular.woff2>; rel=preload; as=font; crossorigin
For more information see here: https://github.com/w3c/preload/issues/32
and here: https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/.
One point worth going over: You have to add a crossorigin attribute
when fetching fonts, as they are fetched using anonymous mode CORS.
Yes, even if your fonts are on the same origin as the page. Sorry.
I'm currently trying to use cassandra_snapshotter with cloud storage in interoperability mode. However event the first request to upload a file fails with a signature mismatch.
Did a small testcase, as even the first request is failing:
import boto
from boto.s3.connection import S3Connection
connection = S3Connection(
aws_access_key_id='GOOGY',
aws_secret_access_key='SECRET',
host='storage.googleapis.com'
)
bucket = connection.get_bucket('foo-cassandra-backups', validate=False)
mp = bucket.initiate_multipart_upload('/g/mnt/cassandra-data2/data/bar/baz-63b205e0618711e7a41cf5e393c7464c/snapshots/20170705150900/manifest.json.lzo')
This fails with:
send: 'POST /g/mnt/cassandra-data2/data/foo/threshold-63b205e0618711e7a41cf5e393c7464c/snapshots/20170705150900/manifest.json.lzo?uploads HTTP/1.1\r\nHost: blubb-cassandra-backups.storage.googleapis.com\r\nAccept-Encoding: identity\r\nDate: Thu, 06 Jul 2017 11:18:46 GMT\r\nContent-Length: 0\r\nAuthorization: AWS BLUBB:F6Ml3vSzDphY7UTGNuf3m+fe19I=\r\nUser-Agent: Boto/2.47.0 Python/2.7.12 Linux/4.4.0-83-generic\r\n\r\n'
reply: 'HTTP/1.1 403 Forbidden\r\n'
header: X-GUploader-UploadID: BLUBB
header: Content-Type: application/xml; charset=UTF-8
header: Content-Length: 447
header: Vary: Origin
header: Date: Thu, 06 Jul 2017 11:18:46 GMT
header: Server: UploadServer
Traceback (most recent call last):
File "foo.py", line 11, in <module>
mp = bucket.initiate_multipart_upload('/g/mnt/cassandra-data2/data/foo/threshold-63b205e0618711e7a41cf5e393c7464c/snapshots/20170705150900/manifest.json.lzo')
File "/usr/local/lib/python2.7/dist-packages/boto/s3/bucket.py", line 1767, in initiate_multipart_upload
response.status, response.reason, body)
boto.exception.S3ResponseError: S3ResponseError: 403 Forbidden
<?xml version='1.0' encoding='UTF-8'?><Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your Google secret key and signing method.</Message><StringToSign>POST
Thu, 06 Jul 2017 11:18:46 GMT
/blubb-cassandra-backups/g/mnt/cassandra-data2/data/foo/threshold-63b205e0618711e7a41cf5e393c7464c/snapshots/20170705150900/manifest.json.lzo</StringToSign></Error>
So i guess the API is not compatible in this case and i'm relatively lost here on how to properly fix it. Additionally i'd like to avoid big changes to the uploader, as we would need to deploy the patches as well.
EDIT: This is with boto 2.47 and i guess it's because AWS requires the ?uploads param but googles API is different and therefore it's not expected in the signature.
Google Cloud Storage does not support the multi-part upload feature of the S3 API, so I would suggest using the regular upload approach (ex. set_contents_from_file()).
I have an API Gateway integration for a method/resource which works when I call it from the API but not when I actually call it:
$ aws apigateway test-invoke-method --rest-api-id $REST_API_ID \
--resource-id $RESOURCE_ID --http-method GET | jq -r .log,.body
This works out fine and I get the following output:
Tue May 16 17:46:42 UTC 2017 : Starting execution for request: test-invoke-request
Tue May 16 17:46:42 UTC 2017 : HTTP Method: GET, Resource Path: /status.json
Tue May 16 17:46:42 UTC 2017 : Method request path: {}
Tue May 16 17:46:42 UTC 2017 : Method request query string: {}
Tue May 16 17:46:42 UTC 2017 : Method request headers: {}
Tue May 16 17:46:42 UTC 2017 : Method request body before transformations:
Tue May 16 17:46:42 UTC 2017 : Endpoint response body before transformations:
Tue May 16 17:46:42 UTC 2017 : Endpoint response headers: {}
Tue May 16 17:46:42 UTC 2017 : Method response body after transformations: { "statusCode": 200 }
Tue May 16 17:46:42 UTC 2017 : Method response headers: {Content-Type=application/json}
Tue May 16 17:46:42 UTC 2017 : Successfully completed execution
Tue May 16 17:46:42 UTC 2017 : Method completed with status: 200
{ "statusCode": 200 }
However, I cannot access this at my URL, which is api.naftuli.wtf/v1/status.json. I have stages defined at glhf, stable, and v1, so by replacing that, you will see different responses. I just simply want a dummy response that returns a 200 JSON blob.
My Terraform for the resources is here as a Gist. Hopefully this fully shows my API Gateway configuration.
If I test invoke this from the CLI or from the web console, I get back what is expected. However, if I curl this from my deployed API at api.naftuli.wtf, I don't get anything nice:
$ for stage in glhf stable v1 ; do
> url="https://api.naftuli.wtf/${stage}/status.json"
> echo "${url}:"
> curl -i -H 'Content-Type: application/json' \
> https://api.naftuli.wtf/${stage}/status.json
> echo -e '\n
> done
https://api.naftuli.wtf/glhf/status.json:
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
Content-Length: 36
Connection: keep-alive
Date: Tue, 16 May 2017 21:41:38 GMT
x-amzn-RequestId: 712ba52b-3a80-11e7-9fec-b79b62d3bf7f
X-Cache: Error from cloudfront
Via: 1.1 da7a5d0ed7f424609000879e43743066.cloudfront.net (CloudFront)
X-Amz-Cf-Id: hBwlbPCP9n2rlz53I-Qb9KoffHB_FoxUCZUaJYNnU3XhCWuMpQTP1Q==
{"message": "Internal server error"}
https://api.naftuli.wtf/stable/status.json:
HTTP/1.1 403 Forbidden
Content-Type: application/json
Content-Length: 23
Connection: keep-alive
Date: Tue, 16 May 2017 21:41:38 GMT
x-amzn-RequestId: 71561066-3a80-11e7-9b00-6700be628328
x-amzn-ErrorType: ForbiddenException
X-Cache: Error from cloudfront
Via: 1.1 0c146399837c7d36c1f0f9d2636f8cf8.cloudfront.net (CloudFront)
X-Amz-Cf-Id: ITX765xD8s4sNuOdXaJ2kPvqPo-w_dsQK3Sq_No130FAHxFuoVhO8w==
{"message":"Forbidden"}
https://api.naftuli.wtf/v1/status.json:
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
Content-Length: 36
Connection: keep-alive
Date: Tue, 16 May 2017 21:41:39 GMT
x-amzn-RequestId: 7185fa99-3a80-11e7-a3b1-2f9e659fc361
X-Cache: Error from cloudfront
Via: 1.1 586f1a150b4ba39f3a668b8055d4d5ea.cloudfront.net (CloudFront)
X-Amz-Cf-Id: dvnOa1s-YlwLSNzBfVyx5tSL6XrjFJM4_fES7MyTofykB3ReU5R1fg==
{"message": "Internal server error"}
My understanding of stages were that they were additional path prefixes to the base path under which all API resources were available. If I had a stage called v1 with a path of /v1, I'd expect that an API Gateway resource for status.json will be basically mapped under /v1, yielding /v1/status.json.
I may be misunderstanding how API Gateway base path mappings and stages work, but CloudWatch tells me that the call is at least happening, though failing for some obscure reason:
21:41:39(c5be3842-6af4-4725-a34f-d6eea8042d17) Verifying Usage Plan for request: c5be3842-6af4-4725-a34f-d6eea8042d17. API Key: API Stage: tcips69qx2/prod_v1
21:41:39(c5be3842-6af4-4725-a34f-d6eea8042d17) API Key authorized because method 'GET /status.json' does not require API Key. Request will not contribute to throttle or quota limits
21:41:39(c5be3842-6af4-4725-a34f-d6eea8042d17) Usage Plan check succeeded for API Key and API Stage tcips69qx2/prod_v1
21:41:39(c5be3842-6af4-4725-a34f-d6eea8042d17) Starting execution for request: c5be3842-6af4-4725-a34f-d6eea8042d17
21:41:39(c5be3842-6af4-4725-a34f-d6eea8042d17) HTTP Method: GET, Resource Path: /v1/status.json
21:41:39(c5be3842-6af4-4725-a34f-d6eea8042d17) Execution failed due to configuration error: statusCode should be an integer which defined in request template
21:41:39(c5be3842-6af4-4725-a34f-d6eea8042d17) Method completed with status: 500
Apparently only traffic across the V1 stage is getting through to CloudWatch logs. I have a misconfiguration somewhere and I can't seem to find it.
Can you try and change you request template in the integration request setup to this:
{
"statusCode": 200
}
API Gateway looks for the status code to return in the response in your integration request template. The response is generated by the mapping template in the integration response. I can see from your terraform setup that you are loading the output json file in the integration request template. This is content API Gateway does not expect.
With Mock Integration Amazon API Gateway there are 2 common reasons for 500 Internal Server error.
Check the mapping template in Integration Request and ensure that you are passing statusCode as an integer to the MOCK Integration endpoint.
{
"statusCode": <Integer_Status_code>
}
Note: Make sure that status code is passed as integer not string.
Correct : 200 Incorrect : "200"
Mock Integrations do not support the binary content. If the API is enabled with bixnary support and has application/json or */* set as binaryMediaTypes, MOCK Integration endpoints would throw a 500 Internal server error when trying to transform the content.
A workaround is to update the contentHandling property of the MOCK Integration to CONVERT_TO_TEXT
Read more here :- https://cloudnamaste.com/500-internal-server-error-mock-integration/
For my case, when I deploy the lambda with serverless framework, the OPTIONS returns 200 when called. However, when I configure manually on AWS API Gateway, it returns 500 Internal Server Error.
When I check the execution log of API gateway, it said
(ee0a42d9-2cfc-4788-8679-00fbd7938cf1) Method request body before transformations: [Binary Data]
(ee0a42d9-2cfc-4788-8679-00fbd7938cf1) Execution failed due to configuration error: Unable to transform request
(ee0a42d9-2cfc-4788-8679-00fbd7938cf1) Gateway response body:
{
"message": "Internal server error"
}
After you create the Resources and OPTIONS methods, select the OPTIONS method then
At Method Execution --> Integration Request --> expand the Mapping Templates, choose "When no template matches the request Content-Type header". Add or select "application/json" in the Content-Type. Click the "application/json", and in the Generate template, paste
{statusCode: 200} without any double quote. Note, if the {"statusCode": 200} exists but with double quote, remove it to be the same as above. Then Save it
At Method Execution --> Integration Response --> expand the 200 response status --> Mapping Template --> Add or select "application/json" in the Content-Type. Make sure that the Generate template box is empty. Then Save it
At Method Execution --> Method Response --> expand the 200 response. In Response Headers for 200, add three headers: Access-Control-Allow-Headers, Access-Control-Allow-Methods, and Access-Control-Allow-Origin. Leave the Response Body for 200 to be empty
Action --> Enable CORS for the Resource
Action --> Deploy API
You have at least two distinct problems with your configuration.
First, one of your three base path mappings doesn't match the way you're trying to invoke your API. Note that the base paths don't have to be the same as your stage names, but they can be if you desire. Since your base path mappings include base paths and stage names, API Gateway is expecting the invoke path to include a base path mapping and not a stage, so it is interpreting the [glhf stable v1] portion of your path as a base path and looking for the corresponding base path mapping entry to determine the API and stage to use. This works fine for the v1 and glhf base paths which return 500 (indicating a different problem). The stable base path (in https://api.naftuli.wtf/stable/status.json) returns a 403 Forbidden because there is no base path of "stable" defined for the domain name api.naftuli.wtf. The stable stage is mapped to the "latest" base path, so calling https://api.naftuli.wtf/latest/status.json should be the way to call the stable stage. This doesn't currently work, and I don't know why. If you tell me what region your running this in, I can look-up the config and do more digging.
The second problem is indicated by the following entry from your CloudWatch logs:
Execution failed due to configuration error: statusCode should be an integer which defined in request template
Can you check that your integration request template (in the file your reference in "${file("${path.module}/files/status.json")}") contains "statusCode: 200" as a top level attribute.
I also found it surprising that you're using the same file for a request template and a response template.
Having had the identical errors I found what helped me solve this issue was to delete my OPTIONS request definition in the AWS Console. I then followed the console's "Enable CORS" form which created a new OPTIONS method.
I subsequently ran terraform plan and looked at the diff between my OPTIONS defintion and theirs. Given that the AWS Console created OPTIONS method worked I applied the changes.
Using terraform 0.12 or greater makes this possible as the terraform plan output detail is more fine grained.
I was doing this in CloudFormation.
It took me a while to get it and the accepted answer here was extremely helpful, but a little vague, so adding some more info.
Stefano Buliani's answer, in CloudFormation YAML, looks like:
RequestTemplates:
application/json: |
{ statusCode: 200 }
What was especially weird here was apparently, the fix was simply to create a deployment using the AWS CLI for each of the stages. Apparently, Terraform was not updating or re-kicking deployments on changes, and so my changes never got out.
I had a similar problem and eventually figured out that my client was using a different content type than I expected. I had foolishly assumed it would use application/json, but it was some custom json thing. In my setup, API Gateway is logging to cloudwatch, which is where I found the content type it received from the client. Once I updated the content type in the request template of the mock integration, things worked as expected.
When reviewing the headers, it appears that the 2nd server to receive the message didn't relay it until AFTER the reported delivery date in the final header.
At c9mailgw11.amadis.com, the reported time was 22:47:49 -0800 (PST). However, the final server, BY2PR0401MB0966.namprd04.prod.outlook.com, reports the time as 06:46:08 +0000.
Is the discrepancy due to something simple, like a bad clock on the amadis relay?
I've written a script that detects email delays, and when I hit an oddity like that I get a negative value from that hop to the next and I want to understand why they are ordered this way to see if I have way to lookahead.
Can anyone offer insight?
**Received: from BY2PR0401MB0966.namprd04.prod.outlook.com (10.160.64.15) by
CY1PR0401MB0971.namprd04.prod.outlook.com (10.160.160.17) with Microsoft SMTP
Server (TLS) id 15.1.403.16 via Mailbox Transport; Wed, 17 Feb 2016 06:46:08**
+0000
Received: from BN3PR0401CA0023.namprd04.prod.outlook.com (10.162.159.161) by
BY2PR0401MB0966.namprd04.prod.outlook.com (10.160.64.15) with Microsoft SMTP
Server (TLS) id 15.1.409.15; Wed, 17 Feb 2016 06:46:07 +0000
Received: from BN3NAM01FT022.eop-nam01.prod.protection.outlook.com
(2a01:111:f400:7e41::207) by BN3PR0401CA0023.outlook.office365.com
(2a01:111:e400:51d1::33) with Microsoft SMTP Server (TLS) id 15.1.409.15 via
Frontend Transport; Wed, 17 Feb 2016 06:46:07 +0000
Received: from BAY004-MC1F22.hotmail.com (10.152.66.51) by
BN3NAM01FT022.mail.protection.outlook.com (10.152.67.153) with Microsoft SMTP
Server (TLS) id 15.1.409.7 via Frontend Transport; Wed, 17 Feb 2016 06:46:06
+0000
Received: from mail2world.com ([209.67.128.125]) by BAY004-MC1F22.hotmail.com with Microsoft SMTPSVC(7.5.7601.23143);
Tue, 16 Feb 2016 22:46:06 -0800
Received: from mail pickup service by mail2world.com with Microsoft SMTPSVC;
Tue, 16 Feb 2016 22:46:04 -0800
ResentFrom: xxx#xxx.com
Return-Path: xxx#xxx.com
Received: from 216.163.188.203 unverified ([216.163.188.203]) by mwpop05oc.mail2world.com with Mail2World SMTP Server;
Tue, 16 Feb 2016 22:46:01 -0800
**Received: from sender153-mail.zoho.com (unknown [74.201.84.153])
by c9mailgw11.amadis.com (Postfix) with ESMTP id A432C5B996A81
for <xxx#xxx.com>; Tue, 16 Feb 2016 22:47:49 -0800 (PST)**
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=zapps768; d=zoho.com;
h=content-type:mime-version:subject:to:from:date;
b=b6BP/HJmeP+ORBz043y8K0tUFE3u3c8tUZvDSHjfuH0zD84gax1wUlRdYGps/SBd7SnFHYT1Plps
wRQOJoRp6hEMPerW6MSOL9psGWfNel4lnZwdtr7ujnuh54CTTEwV
Received: from [192.168.10.1] (xxx.xxx.net [xx.xx.xx.xx]) by mx.zohomail.com
with SMTPS id 1455691501828999.0688176107503; Tue, 16 Feb 2016 22:45:01 -0800 (PST)
The answer to this question is documented in rfc5321, section 4.4 as follows:
When an SMTP server receives a message for delivery or further
processing, it MUST insert trace ("time stamp" or "Received")
information at the beginning of the message content, as discussed in
Section 4.1.1.4.
This line MUST be structured as follows:
o The FROM clause, which MUST be supplied in an SMTP environment,
SHOULD contain both (1) the name of the source host as presented
in the EHLO command and (2) an address literal containing the IP
address of the source, determined from the TCP connection.
o The ID clause MAY contain an "#" as suggested in RFC 822, but
this
is not required.
o If the FOR clause appears, it MUST contain exactly one
entry, even when multiple RCPT commands have been given. Multiple
s raise some security issues and have been deprecated, see
Section 7.2.
An Internet mail program MUST NOT change or delete a Received: line
that was previously added to the message header section. SMTP
servers MUST prepend Received lines to messages; they MUST NOT change
the order of existing lines or insert Received lines in any other
location.
Another possible cause is that Outlook modifies the headers. It does this at least when it moves messages from one IMAP folder to another.
An Outlook bug report was filed for Outlook 2013, but some of this behaviour is still occurring in the latest Outlook desktop version.
It appears that the latest version of Outlook (as of August 2022) still does the following when moving a message from one IMAP folder to another:
it groups all the Received headers together, but in a different order from the original (even though it's not strictly speaking SMTP-related, it's not quite in the spirit of RFC 5321, as quoted by #jstedfast);
it groups all the Authentication-Results headers together, also in a different order (which also makes it complete nonsense if they're not close the Received header they were related to);
it changes the Message-ID header, even if the message hasn't really changed (very much against the spirit of RFC 5322;
it removes the Return-Path and Delivered-To headers.
It's not clear whether this fully matches your use-case, but since your example involves an outlook.com domain at some point in the Received headers, it's possible that other tools in the Outlook family show a similar attitude towards headers than the IMAP-specific use-case I've just mentioned.
I'm trying to create an API using AWS API gateway
first I have created a resource as /sample
then created a method GET
provided Endpoint-URL and saved it.
In the Method Execution pane, select Method Request, added HTTP Request Headers as "Authorization" , added this to pass basic authentication details to back-end url since service is secured with basic authentication,
In the Method Execution pane, choose Integration Request, mapped HTTP Headers, Mapped from as "method.request.path.Authorization"
Choose Method Execution, and in the Client box, choose TEST, passed Header Authorization - Basic XXXXXX
After finished all the configuration successfully, tested the API , getting "message": "Internal server error" status code -500
For your reference my back-end service is running in the amazon-linux machine.
Checked logs:
Execution log for request test-request
Tue Sep 08 16:43:54 UTC 2015 : Starting execution for request: test-invoke-request
Tue Sep 08 16:43:54 UTC 2015 : API Key: test-invoke-api-key
Tue Sep 08 16:43:54 UTC 2015 : Method request path: {}
Tue Sep 08 16:43:54 UTC 2015 : Method request query string: {}
Tue Sep 08 16:43:54 UTC 2015 : Method request headers: {Authorization=************p1c2Vy}
Tue Sep 08 16:43:54 UTC 2015 : Method request body before transformations: null
Tue Sep 08 16:43:54 UTC 2015 : Execution failed due to configuration error: Invalid endpoint address
Could you please let me know how to resolve this issue?
try method.request.header.Authorization
Varun is right, your mapping expression is wrong.
The expression format for parameters in the request is "method.request.[source].[name]" where source is path/querystring/header and name is the name of the parameter as defined in the method request.
For the integration response, the format is the same exception you'd replace request with response and also note that only headers are available to map in the response.
If you want a quick fix just to start and get your API worked then follow these steps:
Steps
Login to AWS console
Go to "API Gateway" dashboard, select the resource(API) you need to invoke then select the method underneath (GET/POST/...)
On the method execution workflow, click on the "Method Response panel" and add status code 200 then you can add some headers for that.
Choose the "Response Body" and add "Application/json" with "Empty" model.
You should also click "Integration Request panel" and uncheck "Use Lambda Proxy integration" [as per attached image]
Last step
deploy your API into the stage(dev/test/prod)