使用http端点访问lambda中的HTTP请求(标头,查询字符串,cookie,正文)对象

Question

我试图看看如何从lambda代码中访问请求标头和正文值.如果请求主体是JSON格式,它似乎会自动解析并在事件对象中可用.

如何在Lambda中访问任何类型的传入"Content-Type"请求的完整查询字符串,请求正文,请求标头(cookie)？

---

以下编辑是我收集的信息,以帮助解决可能相关或不相关的问题.如果你愿意,请忽略它们.

---

编辑:

我在这里和这里详细介绍了SE的现有问题.按照这个线程,使用$input.json('$')应该做的伎俩.我猜上面这些链接的答案已经过时,因为默认情况下API网关似乎在请求中识别JSON,如果是这样,它在event对象中可用,而不配置任何映射模板.

按建议设置映射对我不起作用.它不包含请求标头信息.

以下是有关如何配置的屏幕截图.

---

"headers"键返回一个空值.使用$input.params('$')或"$input.params('$')"错误输出.

---

编辑2

尝试在方法请求中定义标头.仍然没有在lambda中获取User-Agent值.

---

编辑3

我在API网关上使用了以下模板映射

{
    "request": $input.json('$'),
    "headers": "$input.params()"
}

以及lambda中的以下代码

context.succeed("event.key32:"+JSON.stringify(event, null, 2) );

API网关生成的响应显示了这一点

查看响应中的"标题"值,看起来AWS-SDK/API网关/ cloudfront剥离了从HTTP客户端收到的所有标头？以下是$ input.params().标头返回的JSON的全文

header={CloudFront-Forwarded-Proto=https, CloudFront-Is-Desktop-Viewer=true, CloudFront-Is-Mobile-Viewer=false, CloudFront-Is-SmartTV-Viewer=false, CloudFront-Is-Tablet-Viewer=false, Content-Type=application/json, Via=1.1 5d53b9570d94ce920abbd471.cloudfront.net (CloudFront), 1.1 95eea7baa7ec95c9a41eca9e3ab7.cloudfront.net (CloudFront), X-Amz-Cf-Id=GBqmObLRy6Iem9bJbVPrrW1K3YoWRDyAaMpv-UkshfCsHAA==, X-Forwarded-For=172.35.96.199, 51.139.183.101, X-Forwarded-Port=443, X-Forwarded-Proto=https}}

它在标头中没有User-Agent字符串,尽管如上面的屏幕截图所示,它是由REST客户端发送的.有趣的是,整个查询字符串可用.不确定这是否是访问它的预期方式.

Answer 1

可以使用以下方式访问请求标头$input.params('header-name')

令人惊讶的是，上面的代码无法访问 User-Agent 标头。你需要跳过下面的环才能取回它：

$context.identity.userAgent

请求主体/有效负载应该可以使用以下代码访问。更多参考这里、这里和这里：

{
   "reqbody": "$input.path('$')"
}

目前尚不清楚请求正文是否应采用 JSON 格式。需要注意的是，根据这篇文章，请求被视为 UTF-8。

目前似乎有两个错误：

1. “User-Agent”标头丢失/被 Amazon API 剥离。

2. 当标头值包含双引号 (") 时，不会执行 lambda 函数。（我在 cloudwatch 日志中没有看到此类请求的日志条目）。相反，http 响应正文包含以下内容：

   {
      "Type": "User",
      "message": "Could not parse request body into json."
   }
   

Amazon API 中失败的示例请求

我认为需要纠正这个问题才能实现 ETag 缓存机制。

参考：

Etag 应该用双引号引起来。浏览器预计会通过 If-None-Match 标头发送回这个准确的值，这就是 Amazon API 的问题所在。

ETag 的语法？

HTTP：etag 的最大长度

http://gsnedders.com/http-entity-tags-confusion