AWS無服務器Lambda未編碼字符

Question

我在AWS Lambda上有一個簡單的無服務器功能

質量檢查小組決定創建一個卷曲請求，以便在字符“ ^”未編碼時進行測試，即：

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

因此此調用甚至都沒有得到我的代碼，因為它什么也不返回。 空白，沒有。

任何想法如何解決這個問題？ 在lambda上？ ApiGateway？ CloudFront的？

任何想法都會很棒！

謝謝！

詳細的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

現在我在“ 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

Answer 1

您可以忽略X-Cache: Error from CloudFront任何特定含義X-Cache: Error from CloudFront因為它是CloudFront向它處理的任何請求添加的標准標頭，其中HTTP響應代碼> =400。CloudFront基礎結構處理其他請求的傳輸服務，包括API網關邊緣優化的端點和S3傳輸加速（您可以通過嘗試與未啟用傳輸加速功能的存儲桶建立加速連接來生成相同的標頭）。 從本質上講，這意味着“ 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 Gateway中似乎是一個限制-它拒絕此字符並將其稱為“錯誤請求”，這意味着客戶端請求格式錯誤。

看來API Gateway與^存在相同的問題。

在這兩種情況下，拒絕都在API網關基礎架構中發生得如此之早，不僅您的代碼無法看到它……還為時過早，以至於該請求甚至都沒有進入API端點的CloudWatch日志。

在此基礎上，是可能的，甚至有可能不會對你算節流的限制 ，因為API網關可能已經停止解析之前，甚至將其關聯到您的API請求，具體</投機>。

如果將^作為url轉義為%5E ，則API Gateway不會有問題。 實際上，它甚至可以正確解碼並在日志中顯示值：

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

因此，我想說您的質量檢查小組發現API網關存在問題-您需要在查詢字符串中使用url轉義^字符。 但是它返回的是有效的HTTP錯誤代碼……只是沒有響應主體。