This article was also published in HTTPS://GITHUB.COM/ZHANGYACHEN/ZHANGYACHEN.GITHUB.IO/ISSUES/90
When calling the interface through curl, found that the timeout phenomenon is very serious, so ask the other side of the interface, the other side said need to add:
curl_setopt($ch, CURLOPT_HTTPHEADER, array(‘Expect:‘));
After that, I found that it was so, so we investigated the usage.
When using curl for post, when the data to post is greater than 1024 bytes, curl does not directly initiate a POST request, but is divided into 2 steps:
- Send a request that contains a expect:100-continue that asks the server to use a willingness to accept data
- After receiving the 100-continue answer returned by the server, the data is not post to the server
But there are a few things that can happen:
- Not all servers will correctly answer 100-continue, such as LIGHTTPD, and will return 417 expectation Failed.
- caused by the delay, the client sends the first expect:100-continue, waits for the server side to answer before sending the request body.
If you determine that the other side of the server does not reject more than 1024 bytes of Post request, you can not use this method and can also avoid the above mentioned two side effects, the solution is mentioned at the beginning of the article.
About continue
收到了请求的初始部分,请客户端继续。
The purpose of this is: it can let the client before sending the request data to determine whether the server is willing to receive the data, if the server is willing to receive, the client will actually send the data, if the client sends the request data directly, but the server rejected the request, this behavior will bring a lot of resource overhead.
Client behavior
The client sending the continue should not wait for the server to respond forever, after a period of time, the client should send the entity directly.
Server-side behavior
If the server receives a request from continue, it will respond with a continue or send an error code. The server can never send a continue to a client that does not send a continue. But there are servers that do this. IIS 5 incorrectly sending 100-continue response
If the server receives the client's body when it has not yet sent the continue response, then the client decides to start sending the data, so it can no longer send a continue to the client at this time.
Reference: Expect:100-continue
HTTP authoritative Guide 3.4.1
HTTP Header Expect