代码之家 › 专栏 › 技术社区 › Tzook Bar Noy

aws无服务器lambda未编码字符

serverless-framework aws-lambda amazon-web-services

Tzook Bar Noy · 技术社区 · 6 年前

我在aws lambda上有一个简单的无服务器函数

qa团队决定创建一个curl请求,用字符“^”进行测试。当它未编码时,即:

curl -X GET   'https://lambda.com/call?id=inva^lid'

所以这个调用甚至不能到达我的代码,因为它什么也不返回。空白,无。

有什么办法解决这个问题吗? 在兰达身上?阿皮盖特?云锋?

任何想法都会很棒的!

谢谢!

详细卷曲请求:

*   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

现在我在“来自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

1 回复 | 直到 6 年前

Michael - sqlbot 6 年前

你可以忽略 X-Cache: Error from CloudFront 因为它是cloudfront添加到它处理的任何请求的标准头,其中http响应代码为>=400。cloudfront基础设施处理一些其他服务的请求传输,包括api网关边缘优化的端点和s3传输加速(您可以通过尝试与没有传输加速的bucket建立加速连接来生成相同的报头功能已启用)。它本质上意味着“cloudfront处理了这个请求,但有些东西不起作用”——但它并没有提示您具体是什么,因为错误可能是cloudfront的内部或外部错误,而且在这两种情况下都会出现这个头。

为了缩小范围,我做了进一步的测试。事实证明,cloudfront对 ^ 查询字符串参数中的字符。通过cloudfront发行版和自定义源代码确认,此位置的此字符不是问题。

但是api网关会阻塞它。

通过一个区域api端点(它不使用cloudfront进行传输)证实了这一点,api网关阻塞了 ^ 然后回来…几乎什么都没有。

< HTTP/1.1 400 Bad Request
< Date: Thu, 31 May 2018 15:54:59 GMT
< Content-Length: 0
< Connection: keep-alive
<

有类似的记录…

任何请求URL查询字符串都不支持纯文本管道字符(),必须对其进行URL编码。

https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-known-issues.html

在查询字符串中放入一个未转换的管道字符会触发完全相同的行为,因此这似乎是API网关中的一个限制——它拒绝该字符并将其称为“错误请求”,这意味着客户端请求的格式不正确。

似乎API网关与 ^ .

在这两种情况下,拒绝都发生在API网关基础设施中,以至于您的代码不仅看不到它…现在还为时过早,请求甚至都没有到达api端点的cloudwatch日志。

基于此,是 可能的 它甚至可能不算你的 throttling limits 因为API网关可能在将请求关联到您的API之前就已停止分析该请求,特别是</推测>。

如果你用url转义 ^ 作为 %5E ,则API网关没有问题。事实上,它甚至可以正确解码并在日志中显示值:

Method request query string: {id==inva^lid}

所以我认为您的qa团队发现了api网关的问题——您需要url转义 ^ 查询字符串中的字符。但它正在返回一个有效的http错误代码…只是没有反应体。