Curl Simple File Upload - 417 Expectation Failed

cURL Simple File Upload - 417 Expectation Failed

Can also be fixed using set opt header setting:

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

http://www.khattam.info/417-expectation-failed-in-php-curl-while-submitting-multi-part-forms-2011-04-14.html

curl not overwriting header fields

You want to change one header and remove another one, so invoke curl with two -H uses:

 -H 'Content-Type: text/xml' -H 'Expect:'

That is, each -H changes a single header so you need one -H for every header you want to modify.

Combined with the error ikegami pointed out, that means you'd need

push @curl_vars, '-H', 'Content-Type: text/xml';
push @curl_vars, '-H', 'Expect:';

HTTP POST Returns Error: 417 Expectation Failed.

System.Net.HttpWebRequest adds the header 'HTTP header "Expect: 100-Continue"' to every request unless you explicitly ask it not to by setting this static property to false:

System.Net.ServicePointManager.Expect100Continue = false;

Some servers choke on that header and send back the 417 error you're seeing.

Give that a shot.

passing curl file as $_FILES['htmlfile'] with temp_name

Add this in your curl request. It will prevent 417 error.

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

Other possible solutions:
cURL Simple File Upload - 417 Expectation Failed

It's important to know that you are "overwriting" error. It's something like fix but usually is okey. 417 is typical error when you have request between http1.0 and http1.1.

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