AWS Serverless Lambda 未编码字符
AWS Serverless Lambda unencoded character
我在 aws lambda 上有一个简单的无服务器函数
QA 团队决定创建一个 curl 请求以使用字符“^”进行测试
未编码时即：
curl -X GET 'https://lambda.com/call?id=inva^lid'
所以这个调用甚至没有到达我的代码，因为它 returns 什么都没有。
空白，none.
有什么解决办法吗？
在拉姆达？网关？云端？
任何想法都会很棒！
谢谢！
详细的 curl 请求：
* Trying 54.230.159.190...
* TCP_NODELAY set
* Connected to example.com (1.1.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.example.com
* start date: Feb 26 00:00:00 2018 GMT
* expire date: Mar 26 12:00:00 2019 GMT
* subjectAltName: host "example.com" matched cert's "example.com"
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fb1cc00a400)
> GET /call?id=inva^lid HTTP/2
> Host: example.com
> User-Agent: curl/7.54.0
> Accept: application/json
> Cache-Control: no-cache
> Postman-Token: b730c1f2-b8ab-4eeb-b097-99f7d812434a
> api-key: xxxxxxxxxxxxxxxxxxxxxx
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 400
< content-length: 0
< date: Thu, 31 May 2018 12:38:54 GMT
< x-cache: Error from cloudfront
< via: 1.1 xxxxxx.cloudfront.net (CloudFront)
< x-amz-cf-id: -Kn-xxxxxx==
<
* Connection #0 to host example.com left intact
现在我在日志中看到了这个 "Error from cloudfront"
知道如何解决这个问题吗？
现在与 --http1.1
进行相同的调用
* Trying 1.1.1.1...
* TCP_NODELAY set
* Connected to example.com (1.1.1.1) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=*.example.com
* start date: Feb 26 00:00:00 2018 GMT
* expire date: Mar 26 12:00:00 2019 GMT
* subjectAltName: host "example.com" matched cert's "example.com"
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.
> GET /call?id==inva^lid HTTP/1.1
> Host: example.com
> User-Agent: curl/7.54.0
> Accept: application/json
> Cache-Control: no-cache
> Postman-Token: b730c1f2-b8ab-4eeb-b097-99f7d812434a
> api-key: xxxxxxxxx
>
< HTTP/1.1 400 Bad Request
< Content-Length: 0
< Connection: keep-alive
< Date: Thu, 31 May 2018 14:37:26 GMT
< X-Cache: Error from cloudfront
< Via: 1.1 xxxxxxx.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: xxxxxxxxx-J60xxc0TI4MOjQ==
<
* Connection #0 to host example.com left intact
您可以忽略 X-Cache: Error from CloudFront 的任何特定含义，因为它是 CloudFront 添加到其处理的任何请求的标准 header，其中 HTTP 响应代码 >= 400。 CloudFront 基础设施处理一些其他服务的请求传输，包括 API 网关 Edge-Optimized 端点和 S3 传输加速（您可以通过尝试与不包含的存储桶建立加速连接来生成相同的 header '启用传输加速功能）。它本质上意味着 "CloudFront handled this request, and something didn't work" —— 但它并没有给您提示，确切地说，因为错误可能是 CloudFront 内部或外部的错误，并且在这两种情况下都会出现此 header。
为了缩小范围，我做了一些进一步的测试。事实证明，CloudFront 对查询字符串参数中的 ^ 字符没有问题。通过 CloudFront 分配和自定义来源确认，此位置的此字符不是问题。
但是 API 网关阻塞了它。
通过区域 API 端点（不使用 CloudFront 进行传输）确认了这一点，API ^ 和 returns 上的网关阻塞...几乎没有。
< HTTP/1.1 400 Bad Request
< Date: Thu, 31 May 2018 15:54:59 GMT
< Content-Length: 0
< Connection: keep-alive
<
有一个类似的记录案例...
The plain text pipe character (|) is not supported for any request URL query string and must be URL-encoded.
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-known-issues.html
将未转义的管道字符放入查询字符串会触发完全相同的行为，因此这似乎是 API 网关中的一个限制——它拒绝此字符并将其称为 "Bad Request,"表示客户端请求格式错误。
似乎 API 网关与 ^ 有同样的问题。
在这两种情况下，拒绝在 API 网关基础设施中发生得如此之早，以至于您的代码不仅看不到它...它太早以至于请求甚至没有进入 CloudWatch 日志对于 API 端点。
基于此，可能它甚至可能不计入您的 throttling limits 因为 API 网关可能在它之前就停止解析请求将它关联到您的 API，特别是 。
如果你url-escape把^当成%5E，那么API网关就没有问题了。事实上，它甚至正确解码并在日志中显示值：
Method request query string: {id==inva^lid}
所以我想说您的 QA 团队发现 API 网关存在问题——您需要 url-escape 查询字符串中的 ^ 字符。但它正在返回有效的 HTTP 错误代码...只是没有响应 body.
我在 aws lambda 上有一个简单的无服务器函数
QA 团队决定创建一个 curl 请求以使用字符“^”进行测试 未编码时即：
curl -X GET 'https://lambda.com/call?id=inva^lid'
所以这个调用甚至没有到达我的代码，因为它 returns 什么都没有。 空白，none.
有什么解决办法吗？ 在拉姆达？网关？云端？
任何想法都会很棒！
谢谢！
详细的 curl 请求：
* Trying 54.230.159.190...
* TCP_NODELAY set
* Connected to example.com (1.1.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.example.com
* start date: Feb 26 00:00:00 2018 GMT
* expire date: Mar 26 12:00:00 2019 GMT
* subjectAltName: host "example.com" matched cert's "example.com"
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fb1cc00a400)
> GET /call?id=inva^lid HTTP/2
> Host: example.com
> User-Agent: curl/7.54.0
> Accept: application/json
> Cache-Control: no-cache
> Postman-Token: b730c1f2-b8ab-4eeb-b097-99f7d812434a
> api-key: xxxxxxxxxxxxxxxxxxxxxx
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 400
< content-length: 0
< date: Thu, 31 May 2018 12:38:54 GMT
< x-cache: Error from cloudfront
< via: 1.1 xxxxxx.cloudfront.net (CloudFront)
< x-amz-cf-id: -Kn-xxxxxx==
<
* Connection #0 to host example.com left intact
现在我在日志中看到了这个 "Error from cloudfront"
知道如何解决这个问题吗？
现在与 --http1.1
* Trying 1.1.1.1...
* TCP_NODELAY set
* Connected to example.com (1.1.1.1) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=*.example.com
* start date: Feb 26 00:00:00 2018 GMT
* expire date: Mar 26 12:00:00 2019 GMT
* subjectAltName: host "example.com" matched cert's "example.com"
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.
> GET /call?id==inva^lid HTTP/1.1
> Host: example.com
> User-Agent: curl/7.54.0
> Accept: application/json
> Cache-Control: no-cache
> Postman-Token: b730c1f2-b8ab-4eeb-b097-99f7d812434a
> api-key: xxxxxxxxx
>
< HTTP/1.1 400 Bad Request
< Content-Length: 0
< Connection: keep-alive
< Date: Thu, 31 May 2018 14:37:26 GMT
< X-Cache: Error from cloudfront
< Via: 1.1 xxxxxxx.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: xxxxxxxxx-J60xxc0TI4MOjQ==
<
* Connection #0 to host example.com left intact
您可以忽略 X-Cache: Error from CloudFront 的任何特定含义，因为它是 CloudFront 添加到其处理的任何请求的标准 header，其中 HTTP 响应代码 >= 400。 CloudFront 基础设施处理一些其他服务的请求传输，包括 API 网关 Edge-Optimized 端点和 S3 传输加速（您可以通过尝试与不包含的存储桶建立加速连接来生成相同的 header '启用传输加速功能）。它本质上意味着 "CloudFront handled this request, and something didn't work" —— 但它并没有给您提示，确切地说，因为错误可能是 CloudFront 内部或外部的错误，并且在这两种情况下都会出现此 header。
为了缩小范围，我做了一些进一步的测试。事实证明，CloudFront 对查询字符串参数中的 ^ 字符没有问题。通过 CloudFront 分配和自定义来源确认，此位置的此字符不是问题。
但是 API 网关阻塞了它。
通过区域 API 端点（不使用 CloudFront 进行传输）确认了这一点，API ^ 和 returns 上的网关阻塞...几乎没有。
< HTTP/1.1 400 Bad Request
< Date: Thu, 31 May 2018 15:54:59 GMT
< Content-Length: 0
< Connection: keep-alive
<
有一个类似的记录案例...
The plain text pipe character (|) is not supported for any request URL query string and must be URL-encoded.
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-known-issues.html
将未转义的管道字符放入查询字符串会触发完全相同的行为，因此这似乎是 API 网关中的一个限制——它拒绝此字符并将其称为 "Bad Request,"表示客户端请求格式错误。
似乎 API 网关与 ^ 有同样的问题。
在这两种情况下，拒绝在 API 网关基础设施中发生得如此之早，以至于您的代码不仅看不到它...它太早以至于请求甚至没有进入 CloudWatch 日志对于 API 端点。
基于此，可能它甚至可能不计入您的 throttling limits 因为 API 网关可能在它之前就停止解析请求将它关联到您的 API，特别是 。
如果你url-escape把^当成%5E，那么API网关就没有问题了。事实上，它甚至正确解码并在日志中显示值：
Method request query string: {id==inva^lid}
所以我想说您的 QA 团队发现 API 网关存在问题——您需要 url-escape 查询字符串中的 ^ 字符。但它正在返回有效的 HTTP 错误代码...只是没有响应 body.