问题标签 [transfer-encoding]

我有一个使用 spring saml 和 Modsecurity 的基于 Java-Servlet 的 Web 应用程序。

对于其中一个 GET 请求（URL - /saml/login），响应是返回为 text/html 的 HTML 页面（我可以在浏览器网络工具中读取 html 文件）以及 Content-Length 标头。这是 Modsecurity 被禁用的时候。

当我在应用程序中启用 ModSecurity 时，将返回相同的响应，并带有标头 Transfer-encoding: chunked。这次 html 响应由于分块而被编码。例如<html显示为10<60h104t116m109l108。我不确定浏览器是否应该对此进行解码，但这破坏了我的应用程序的流程。由于响应以编码形式显示在浏览器上。

我尝试在 ModSecurity 中注释掉规则，以找出导致响应被分块但没有成功的原因。由于另一个开发人员实现了 ModSecurity，此时我不确定如何通过更改 ModSecurity 来解决这个问题。

因此，我想尝试在 Java 代码或浏览器中解码响应。如果 Html 文件渲染正常，后续的请求就会开始工作。

编辑1：

web.xml 中的 ModsecurityFilter 配置：

我正在尝试使用内置的 PHP 邮件功能来发送包含我的消息的 html 和纯文本版本的多部分消息。我一直在玩不同的编码类型，但是我一直遇到问题。最初我设置Content-Transfer-Encoding为Binary但是，这导致每 78 个字符放置一个感叹号。我也尝试过base64，但我相信 base64 对我正在做的事情来说太过分了。

我所做的只是发送基本的 HTML，没有编码的图像、文件或附件。我更喜欢一种仍然允许源代码可读的编码方法。

我听说这Quoted-Printable就是我正在寻找的东西，但是，当我尝试使用该编码类型发送消息时，结果看起来真的很奇怪。"我注意到消息源代码中散布着一堆符号。

这是我正在使用的代码：

我到底做错了什么？

我正在寻找一种在 C# 中创建支持多部分形式帖子的分块传输编码的 HttpServer 的方法。原因是我需要传输大文件（2-10GB）并且客户端应用程序必须使用分块传输编码 - 否则在将文件加载到内存时它会耗尽内存。我查看了网络并发现了很多使用 .Net 中的 System.Net.HttpListener 类的示例，但我无法让该示例用于从使用分块传输编码的客户端接收数据.

有没有人有如何做到这一点的例子？

非常感谢任何提示。

提出类似问题的问题：

使用 HTTP/1.1 时 LWP 的问题：块大小错误，响应被截断。

我正在使用 Perl 模块WWW::Mechanize来抓取网站。据我了解，WWW::Mechanize 使用 Net::HTTP 模块来实现 HTTP 协议。

这是问题：

当我执行上面的代码片段时（假设所有导入都到位），我得到一个空的响应内容，在 WWW:Mechanize 的响应对象内的响应标头中出现以下错误：

注意异常消息中的“{”。然后我尝试调试 Methods.pm 模块以查看发生了什么，看起来异常发生在read_entity_body子例程中。

我还为我拥有的 url 做了一个curl并得到了以下响应头：

并具有以下内容：

如果我没记错的话，看起来从网站传来的内容实际上并不是块编码的，尽管标题中提到了要分块的传输编码。

有关 Methods.pm 模块的更多信息：

据我了解，read_entity_body子例程尝试解码并组合块以形成响应内容。

我认为问题在于响应标头具有 Transfer-Encoding: chunked 但内容实际上没有被分块编码。

非常感谢任何帮助。谢谢。

编辑1：

版本：

WWW:Mechanize: 1.83 , LWP:UserAgent: 6.15和 Net::HTTP: 6.12

编辑2：

输出curl -s --raw -D - "https://...."：

与之前的 JSON 内容一样，我删除/更改了一些值只是为了匿名数据。

编辑3： 这是我执行以下命令时得到的：

编辑 4： TCP 转储：

在一个终端窗口中执行了以下命令：

以下是另一个：

漂亮的打印 tcpdump 使用：

TCP转储：

我正在尝试仅使用套接字构建准系统 HTTP/1.1 客户端。每当我尝试使用 Transfer-encoding: chuncked 时，代码都会给我以下状态：502 Bad Gateway。

这给了我以下o / p：

如果我删除 'Transfer-encoding: chunked' 标头，它工作正常。

我正在尝试将一些数据发送到需要“Transfer-encoding: chunked”标头的 Web 服务。它适用于正常的 POST 请求。但是只要我添加标题，我总是会得到：

由于以下情况，无法传递内容：收到来自客户端的无效请求

这是发送请求的部分：

我不得不从不同的文件中复制它，所以我希望我得到了所有重要的变量定义。现在我只同步使用它，因为我认为它更容易调试。

由于它适用于普通的 POST 请求（我只是将 WinHttpSendRequest 与有效负载一起使用），我猜它一定与我使用 WinHttpSendRequest 和 WinHttpWriteData 的方式有关，我只是不知道应该如何使用它。

任何帮助表示赞赏！

我在 IIS 8.5 上运行了 ASP.NET Web API，我的 POST 方法接收了一个 json 文档的正文。现在一个客户端应用程序正在使用 apache httpclient，它显然会自动将 Transfer-Encoding: chunked 标头添加到请求中。我的 API 方法由于正文不存在而引发异常 - 它无法反序列化正文中的 json，即使它在客户端日志中看起来不错。

我应该如何处理请求以确保我得到整个身体？我猜 IIS 也应该支持请求的传输编码，因为它是 HTTP/1.1 规范的一部分，对吧？

有一个类似的问题未回答：Reading Body on chunked transfer encoded http requests in ASP.NET

golang 的 net/http 包是否支持分块传输编码的请求？到目前为止，我已经能够使用 Hijacker 界面（https://golang.org/src/net/http/server.go?s=6173:6875#L156）至少不关闭连接并接收完整的分块请求，但尚未解析块，并怀疑我可能走错了路。

来自https://golang.org/src/net/http/httputil/httputil.go?s=688:732#L10，我看到有一个分块阅读器，但似乎是供内部使用的。

本质上，我正在尝试接受带有“分块”传输编码的 HTTP PUT，并将其“即时”发送到后端服务器（即不缓冲 golang 中的完整请求）。我无法控制上游请求。有没有推荐的方式来处理这样的请求，或者是劫持者的方式来做到这一点？

如果我在 nginx、uwsgi 和烧瓶中使用分块传输编码，我总是会Content-Length与Transfer-Encoding: chunked. 但是，HTTP 1.1 禁止这种行为。我试图配置 nginx 和 uwsgi 以实现所需的行为（Content-Length在 header 中没有 when Transfer-Encoding: chunked）但没有成功。首先，有我的服务器和客户端代码：

服务器代码（server.py）：

客户代码（client.py）：

如果我运行服务器并尝试使用客户端连接到服务器，我会得到以下输出。服务器输出：

客户端输出：

目前，一切似乎都很好。在标题中，我们Transfer-Encoding没有Content-Length. 现在，我尝试合并 uwsgi ( uwsgi.py)：

我运行以下命令：

输出与之前的尝试相同。因此，还是如预期的那样。现在，我将尝试部署 nginx。我的 uwsgi 配置（uwsgi.ini）：

我的 nginx 配置（/etc/nginx/nginx.conf）：

我启动 nginx，然后运行：

现在，输出包含Content-Length：

proxy_request_buffering我为 nginx: , proxy_buffering, proxy_http_versionand chunked_transfer_encodingin the serverand locationcontext尝试了不同的设置，但没有成功。我添加X-Accel-Buffering: no到标题，但它没有解决问题。此外，我为 uwsgi: wsgi-manage-chunked-input, http-raw-body,尝试了不同的选项http-auto-chunked，http-chunked-input但没有实现所需的行为（Content-Length仍然存在于带有 的标题中Transfer-Encoding: chunked）。

我使用以下版本的烧瓶、uwsgi 和 nginx：

知道有什么问题吗？谢谢。

我正在使用 REST API 创作一个服务，它使人们能够上传某些类型的文档。我希望在上传期间压缩这些文档（出于带宽原因），但它们不会以压缩方式存储在我的服务中。我确实有一个客户端 SDK，但客户可以根据我发布的 REST 文档自由实施他们自己的库来上传内容。我在这里查看了最佳答案，并确定传输编码可能是执行此操作的更合适的机制。

但是，在 PUT 请求期间启用传输编码的文档/示例非常少。RFC 似乎在从服务器传输编码响应方面花费了大量文本，但反之则不然。

如果我选择走这条路，我想澄清一些事情：

1. 根据RFC 7230，gzip 的传输编码必须始终使用分块的第二种编码。就我而言，这不是严格要求的，因为发件人确实知道正在发送的文件的完整长度。但按照标准，我必须在服务器上实现分块编码。RFC 指出，如果指定了传输编码，则不应指定内容长度，并且应使用分块编码帧来描绘消息的结尾。这是准确的吗？我问这个是因为我的服务需要支持分块编码，如果可能的话，我想避免编写它。
2. 对于传输编码的响应，有一种机制（TE：Transfer-Encoding:）供服务器与客户端协商其支持的算法。但是对于客户端到服务器的交互没有这样的机制。如果出于某种原因，将来我想在我的服务中停止对 gzip 传输编码的支持，除了将 501（未实现）错误返回给客户端之外，还有其他选择吗？这将是一种重大变化，可能会使一些客户端完全停止工作。理想情况下，我希望客户端查询服务器是否支持特定编码，然后才开始使用该编码发送消息。有什么有趣的方法可以做到这一点吗？