How to Stop Curl from Using 100 Continue

How to handle 100 continue HTTP message?

If you are using libcURL to write your client-side program, make sure you set the CURLOPT_FAILONERROR option to 1. For example, in C, you would do something like:

curl_easy_setopt (curl_handle, CURLOPT_FAILONERROR, 1L);

According to the libcURL documentation, this option
"tells the library to fail silently if the HTTP code returned is equal to or larger than 400."

Furthermore, the documentation makes it clear that "the default action would be to return the page normally, ignoring that code."

If you are using the curl command line tool, simply adding -f or --fail into your curl command will cause similar behaviour as described above. This is also described in the curl man page.

Note that both these methods are not fail-safe, as is clearly stated in the docs:

"This method is not fail-safe and there are occasions where non-successful response codes will slip through, especially when authentication is involved (response codes 401 and 407)."

curl, play & expect 100 continue header

the problem was in my curl command. I used the -d argument, which is a short for --data or --data-ascii, when I should have used --data-binary argument.

PHP curl_exec returns both HTTP/1.1 100 Continue and HTTP/1.1 200 OK separated by space

I will opt for #1.
You can force curl to send empty "Expect" header, by adding:

curl_setopt($ch, CURLOPT_HTTPHEADER,array("Expect:"));

to your code

If you want check it manually, you should define your own header callback and maybe write callback (look for CURLOPT_HEADERFUNCTION and CURLOPT_WRITEFUNCTION in curl_setopt doc), which has simply to ignore all "HTTP/1.1 100 Continue" headers.

Curl doesn't send entire form-data in HTTP POST request

Problem 1

I have checked the request headers and found Expect: 100-continue header. This is the first time I have seen this header.

A simple search in Google shows this is causing the problem.

Expect: 100-Continue' Issues and Risks (I'm just gonna paste everything to avoid dead link)

How the Expect: 100-Continue Header Works

When Expect: 100-Continue is NOT present, HTTP follows approximately the following flow (from the
client's point of view):

1. The request initiates a TCP connection to the server.

2. When the connection to the server is established, the full request--which includes both the request headers and the request body--is transmitted to the server.

3. The client waits for a response from the server
(comprised of response headers and a response body).

4. If HTTP
keep-alives are supported, the request is optionally repeated from
step 2.

When the client is using the Expect: 100-Continue feature, the
following events occur:

1. The request initiates a TCP connection to the server.

2. When the
connection to the server is established, the request--including the
headers, the Expect: 100-Continue header, without the request body--is
then transmitted to the server.

3. The client then waits for a response
from the server. If the status code is a final status code, using the
prior steps above the client retries the request without Expect:
100-Continue header. If the status code is 100-Continue, the request
body is sent to the server.

4. The client will then wait for a response
from the server (comprised of response headers and a response body).

5. If HTTP keep-alives are supported, the request is optionally repeated
from step 2.

Why use Expect: 100-Continue?

API POST requests that
include the Expect: 100-Continue header save bandwidth between the
client and the server, because the server can reject the API request
before the request body is even transmitted. For API POST requests
with very large request bodies (such as file uploads), the server can,
for example, check for invalid authentication and reject the request
before the push body was sent, resulting in significant bandwidth
savings.

Without Expect: 100-Continue:

Without the Expect: 100-Continue
feature, the entire API request, including the (potentially large)
push body would have to be transmitted before the server could even
determine if the syntax or authentication is valid. However, since the
majority of our API requests have small POST bodies, the benefits of
separating the request header from the request body is negligible.

Problems when the request header and body are sent separately

Because
of the high volume of requests that Urban Airship handles, many levels
of complexity exist between our clients and the servers responsible
for responding to API requests. This is not an abnormal phenomenon for
most server configurations and strategies, but it does introduce a
risk of elevated request failures to any API POST requests using the
Expect: 100-Continue header. This is due to the fact that the request
header and the request body are sent separately from one another, and
must travel through the same connection throughout the entire API
server infrastructure.

With the number of proxies, load-balancing servers, and back-end
request processing servers that are implemented, requests with the
Expect: 100-Continue header have an increased probability of becoming
separated from one another, and hence returning with an error.

What To Expect:

We've always attempted to support Expect: 100-Continue.
However, we have determined that our customers that use Expect:
100-Continue are receiving a sub-optimal quality of service due to
elevated request failures.

Additionally, the majority of our API requests have small POST bodies,
and as a result the benefits of separating the request header from the
request body are negligible. These reasons have motivated us to
disable support for Expect: 100-Continue service-wide.

Our Recommendations:

We recommend against the use of Expect:
100-Continue. If you receive an HTTP Error 417 (Expectation failed),
retry the request without Expect: 100-Continue.

So, to prevent Expect: 100-continue header in POST form-data, include -H 'Expect:' in your `curl

curl -X POST -F "name=user" -F "password=test" localhost:8080 -H 'Expect:'

Now you can receive your entire data in one go(just like Postman) as you said in comments.

---

Problem 2 & 3

As @melpomene said in comments, read() doesn't put \0 after reading. That's why you are seeing data from previous requests.

So, just use valread to iterate over string to print or just declare variable in your while loop as I said in the comments.

Code:

while(1)
    {
        printf("\n+++++++ Waiting for new connection ++++++++\n\n");
        if ((new_socket = accept(server_fd, (struct sockaddr *)&address, (socklen_t*)&addrlen))<0)
        {
            perror("In accept");
            exit(EXIT_FAILURE);
        }

        char buffer[30000] = {0};  // This way you get new variable everytime. So, there is no need to iterate over the string using valread value.
        valread = read( new_socket , buffer, 30000);
        printf("%s\n",buffer );
        write(new_socket , hello , strlen(hello));
        printf("------------------Hello message sent-------------------%lu\n", valread);
        close(new_socket);
    }

---

Related Topics