HTTP/1.1 协议 Expect: 100 -continue 分析与禁用

是 The Lin 呀

已于 2022-03-17 22:00:47 修改

阅读量5.4k

点赞数 2

分类专栏：计算机网络文章标签： http 网络协议网络

于 2022-03-17 21:11:43 首次发布

本文链接：https://blog.csdn.net/weixin_44798320/article/details/123560430

版权

这篇博客详细介绍了HTTP/1.1协议中的Expect: 100-continue机制，讨论了libcurl在发送大量数据时如何使用该机制，并指出其可能带来的延迟问题。同时，文中还提供了在C#中禁用这一特性的方法。读者将了解到这一特性如何影响客户端与服务器之间的交互，以及如何处理不支持此特性的服务器。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1、基础知识背景

1.1 “Expect: 100-continue”的是什么：
HTTP/1.1 协议里，设计 100 - continue HTTP 状态码的，目的是为了在 client 发送 Request Message 之前， HTTP/1.1 协议允许 client 判定服务器是否愿意接受 client 的消息主体(基于 Request Message )。
如果 client 预期等待 100-continue 应答，那么它发送的请求必须包含一个 Expect: 100 -continue 的头域。

2、Expect: 100-continue 来龙去脉

2.1 libcurl 发送大于1024字节数据时启用“Expect:100-continue‘特性：
2.2 这也就是 Laruence 在 2011 年撰文所写的：
在使用 curl 做 POST 的时候，当要POST 的数据大于 1024 字节的时候，curl 并不会直接就发起 POST 请求，而是会分为两步：
发送一个请求，包含一个 “Expect:100-continue” 头域，询问 Server 是否愿意接收数据；
接收到 Server 返回的100-continue 应答以后，才把数据 POST 给Server；
这是 libcurl 的行为。

2.3 zxgfa在 2012年补充说：
libcurl在发送大于1024 字节的 POST 请求时采用了这种方法，但是相对的，它会引起请求延迟的加大。
并不是所有的 web server 都能正确处理并应答“100-continue”&