问题标签 [http-status-code-100]

是否可以在使用 Java Servlet API (HttpServletResponse) 处理整个请求后发送“100 Continue”HTTP 状态代码，然后再发送一些其他状态代码？

我找不到任何明确的“否”答案，尽管 API 似乎不支持它。

Expect: 100-continue我正在使用 ASP.NET MVC 实现一个 REST API，并且以请求标头的形式出现了一个小绊脚石，用于带有帖子正文的请求。

RFC 2616指出：

在接收到一个包含“100-continue”期望的 Expect 请求头字段的请求时，源服务器必须要么以 100（继续）状态响应并继续从输入流中读取，要么以最终状态码响应。源服务器在发送 100（继续）响应之前不能等待请求正文。如果它以最终状态码响应，它可以关闭传输连接，或者它可以继续读取并丢弃请求的其余部分。如果它返回一个最终状态码，它绝不能执行请求的方法。

这听起来像是我需要对请求做出两个响应，即它需要立即发送一个 HTTP 100 Continue 响应，然后继续从原始请求流（即HttpContext.Request.InputStream）读取而不结束请求，然后最终发送结果状态码（为了论证，假设它是 204 No Content 结果）。

所以，问题是：

1. 我是否正确阅读规范，我需要对请求做出两个响应？
2. 这如何在 ASP.NET MVC 中完成？

wrt (2) 在继续读取输入流之前，我尝试使用以下代码...

...但是当我尝试设置最终的 204 状态代码时，我得到了错误：

System.Web.HttpException：发送 HTTP 标头后服务器无法设置状态。

我有一个 ASP.NET 应用程序，它接收来自客户端软件的请求，并且请求标头包含“请求 100-继续”。

我想覆盖 IIS 对 request-100 标头的自动响应，以便我可以使用其他标头来验证用户（或不验证）并根据状态发送正确的响应（100 继续进行身份验证）或正确的错误消息.

我正在开发一个 PHP webapp，它接受来自特定客户端的大型 POST 文件上传，并希望在使用 HTTP/1.1 100 上传文件之前接受或拒绝这些上传（基于各种标头和其他因素，而不仅仅是大小）继续。

HTTP/1.1 规范 8.2.3的一些快速背景知识：

100（继续）状态（参见第 10.1.1 节）的目的是允许正在发送带有请求正文的请求消息的客户端确定源服务器是否愿意接受请求（基于请求标头）在客户端发送请求正文之前。在某些情况下，如果服务器在不查看正文的情况下拒绝消息，则客户端发送正文可能不合适或效率极低。

问题是Apache从客户端看到Expect：100-continue，返回100 Continue并在PHP开始处理之前接受所有文件上传......但是我需要PHP在Expect：100-continue之后立即开始处理。我不确定这是否可能，所以我有两个问题：

1. 是否可以让 PHP 在 Expect: 100-continue 之后立即开始处理？
2. 如果没有，有什么好的选择？

我目前正在考虑通过指定客户端首先发送与 POST 具有相同标头的 HEAD 请求来模拟 100 continue。然后，webapp 可以返回响应以继续 POST 或错误代码。欢迎其他建议！

注意：我们在客户端使用 lib_neon，在服务器端使用 Tomcat 和 servlet api。

问题如下：当客户端想要放置一些内容时，它会执行一个带有“Expect: 100-continue”标头的 PUT 请求，Tomcat 通过简单地返回状态 100 Continue 来处理它，然后客户端开始发送请求的剩余部分，并且它被我们的自定义过滤器处理并且通常它不会通过（例如用户未授权，或者试图放置太大的文件，超过用户限制，或其他）。过滤器立即发送错误响应，但客户端仅在提交完整请求正文时才读取响应。

似乎不可能手动发送一些东西而不是 100 Continue 状态，当一些检查失败时，并且这种行为被硬编码到tomcat中，当不可能时，有没有其他方法不上传请求正文？

我编写了一个 ASP.Net 网页，它将获取一个QueryString文件并将其流式传输到客户端。该文件存储在 SQL Server 数据库中。当我在开发过程中在本地运行网站时，一切都很好。当我从服务器在生产中运行它时，我可以通过 Firefox 获取文件，但不能通过 Chrome 获取。在 Chrome 中我得到Error 100 (net::ERR_CONNECTION_CLOSED): Unknown error.

请参阅其他一些提到这可能与 相关的帖子Content-Length，但是，我不明白为什么这会在开发而不是生产中起作用。出于这个原因，我认为这里一定有其他事情发生。

感谢您的任何建议/提示。

这是我的代码：

我的标题如下：

许多库Expect: 100-continue默认包含所有 HTTP 1.1 POST 和 PUT 请求。

我打算通过删除客户端上的 100-continue 机制来减少感知延迟，因为我知道立即发送数据的费用低于等待 100-continue 的往返，即短请求。

当然，我仍然想要 HTTP 1.1 的所有其他强大功能，因此我只想杀死Expect: 100-continue标头。我有两个选择：

• 完全删除期望标头，或
• 发送空的期望标头，Expect:\r\n

两者之间有什么区别吗？

任何软件可能会因其中之一而中断？

我正在尝试使用带有 php curl 的 Web 服务，但我收到 http 代码“100”和“Recv 失败：连接已重置”错误。我使用 google chrome 的扩展名“Postman -REST Client”测试了 Web 服务"而且效果很好。我搜索了这个 http 代码，看起来服务器正在等待正文请求数据，但我不知道它希望我发送什么，因为我没有发布任何数据，只是标题。

我的代码如下所示：

我发送的标题如下所示：

我实例化了一个 netty 4（使用 netty-all-4.0.9.jar）服务，并通过添加 3 个 ChannelHandler 对象来初始化通道：

当测试 w/ curlHTTP PUT将文件发送到我的服务器时，我发现MyHandler.channelRead没有立即调用带有标头的请求Expect: 100-continue（curl 正在等待服务器回复100 Continue. 这意味着我的处理程序无法回复HTTP/1.1 100 Continue以告诉客户端（curl）立即启动文件的实际上传。

有趣的是，进一步调试这个问题telnet表明，channelRead一旦上传了实际的正文（在收到第一个字节之后），就会立即调用 a。

关于如何正确处理PUT带有“期望：100-继续”标头的请求以100 Continue立即触发响应的任何提示？

我正在使用 libcurl (c++) 库向 IIS 7.5 服务器发出请求。该事务是一个常见的 SOAP Web

服务 一切正常，我的请求发送一个“期望 100-继续”标志，服务器以 100-继续响应，然后立即响应 200 ok 代码以及 Web 服务响应。

但有时，客户端会收到一条 100-continue 消息，然后又收到 100 个代码。这会使客户端报告错误，因为它期望在服务器 100 代码之后立即出现最终状态代码。我在 W3C HTTP1.1 协议中阅读：

发送 100（继续）响应的源服务器必须最终发送最终状态代码，一旦请求主体被接收和处理，除非它提前终止传输连接。

“最终”这个词让我迷失了方向。服务器在最终状态代码之后发送几个 100 个代码是否可能/常见？

如果有人以前遇到过这个问题，可以指出关于如何使用 libcurl 处理多个 100 响应代码的任何解释吗？

提前致谢