对付100-continue这个字段，RFC文档（http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3）是这么阐明的：它可以让客户端在发送要求数据之前去判断做事器是否乐意吸收该数据，如果做事器乐意吸收，客户端才会真正发送数据。这么做的缘故原由是如果客户端直接发送要求数据，但是做事器又将该要求谢绝的话，这种行为将带来很大的资源开销。
所以为了避免这种情形，libcurl在发送大于1024字节的POST要求时采取了这种方法。但是相对的，它会引起要求延迟的加大，其余并不是所有的server都会精确处理并且应答100-continue，比如lighttpd，就会返回417 Expectation Failed，造成要求处理出错。
如果确定做事器不会谢绝1024个字节以上的POST要求，就可以不该用该方法，而且也可以避免以上提到的两个副浸染。
办理办法：
（1）阻挡Gateway转发Expect header要求参数
可以在Spring Cloud Gateway中阻挡转发Expect要求参数，在路由中添加如下代码即可：
.filters((t)->t.removeRequestHeader("Expect"))
（2）在application.yml 配置文件中添加配置
如下所示，添加filter配置-RemoveRequestHeader。
spring: cloud: gateway: routes: - id: removerequestheader_route uri: https://example.org filters: - RemoveRequestHeader=Expect加上这段就好了，实在要求流程是能走通的。只是要求的时候带有Except没有数据返回。但是如果不走网关直接调用微做事的话，Spring Boot项目是能处理的。估计是Gateway是基于Netty的缘故原由，也便是说这个可能是Netty引发的bug。
（3）在发起要求时，就取消Expect要求参数
示例代码如下，取消Expect要求参数：
HttpWebRequest request = WebRequest.Create(uri.Uri) as HttpWebRequest;
reqrequest.ServicePoint.Expect100Continue = false; // 取消100-continue
