问题描述

客户端使用Httpclient或HttpWebRequest请求API服务器时得不到响应，但是采用PostMan调用对应的接口时又可以得到响应结果。

处理过程

1、使用抓包工具Fiddler进行HTTP请求抓包。对比两个请求的请求头信息发现PostMan调用接口时少了Expect:100-continue这个请求头。
2、即使在开发中，Httpclient或HttpWebRequest没有添加指定Expect也会自动默认添加Expect:100-continue。
3、通过查询资料，关闭对应客户端Expect请求头(关闭方式如下)。再重新发起请求，果然就获得到了响应

// Httpwebrequest:
myRequest.ServicePoint.Expect100Continue = false;
// Httpclient:
httpClient.DefaultRequestHeaders.ExpectContinue = false;

问题分析

理解

网上查找请求头Expect: 100-continue的作用是什么，查询结果整理如下
HTTP/1.1协议里设计100 (Continue)HTTP状态码的的目的是，在客户端发送Request Message之前，HTTP/1.1协议允许客户端先判定服务器是否愿意接受客户端发来的消息主体（基于Request Headers）。即客户端在较大的Post数据到服务端之前，允许双方“握手”，如果匹配上了，客户端才开始发送较大的Post数据。
这么做的原因是，如果客户端直接发送请求数据，但是服务器又将该请求拒绝的话，这种行为将带来很大的资源开销。
协议对HTTP客户端的要求是：如果客户端预期等待100-continue的应答，那么它发的请求必须包含一个Expect: 100-continue请求头

策略

客户端策略

1. 如果客户端有Post数据要上传，可以考虑使用100-continue协议。在请求头中加入Expect: 100-continue。
2. 如果没有Post数据，不能使用100-continue协议，因为这会让服务端造成误解。
3. 并不是所有的服务器都会正确实现100-continue协议，如果客户端发送Expect: 100-continue消息后，在Timeout时间内无响应，需要立马上传Post数据。
4. 有些服务器会错误实现100-continue协议，在不需要此协议时返回100，此时客户端应该忽略。

服务端策略

1. 正确情况下，收到请求后，返回100或错误码。
2. 如果在发送100-continue前收到了Post数据（客户端提前发送Post数据），则不发送100响应码(略去)。

结论

如果确定服务器不会拒绝1024个字节以上的POST请求，可以关闭客户端请求头Expect: 100-continue，避免客户端请求时出现得不到服务器响应的问题