Ajax wird heute in fast jeder modernen Webanwendung genutzt, bietet doch jedes gute Javascript-Framework mittlerweile einfache Möglichkeiten XHR-Anfragen abzusetzen. In diesem Artikel soll es aber nicht um die Client-Seite gehen, sondern darum, wie man…

Telnet is line-buffering. The server will actually respond as soon as you finish typing “Foo”, but telnet just isn’t sending the data until you hit enter. This can be confusing if you don’t know about it, since it looks like it’s something the server is doing, when it’s actually the client.

I did a quick test. On the server I placed this file:

if ($_SERVER['REQUEST_METHOD'] == 'POST') {
    $entity = file_get_contents('php://input');
    echo 'Content-Length: ' . $_SERVER['CONTENT_LENGTH'] . "\n";
    echo 'Actual length: ' . strlen($entity) . "\n";
    echo 'Entity body: ' . $entity . "\n";
}

From telnet, I posted this data:

POST /~ramsey/http/length.php HTTP/1.1
Host: localhost
Content-Length: 3

Foo bar. This is a longer entity than the Content-Lenth says.

What I got back in response was:

Content-Length: 3
Actual length: 3
Entity body: Foo

If I set Content-Length to 100, however, the server appears to wait until I’ve submitted the full 100 bytes, or it times out—whichever comes first.

So, yeah, I’ll put a note in the body of this post soon, but I’ll also make a new blog post to explain my fallacy and I’ll link to that post from here.

Thanks!

If it’s just a plain, non-chunked request (T-E: identity), you can’t give a fake Content-Length, because the header itself defines the amount of data that’s going to be read as the request body. If you say Content-Length: 1, and then write a gigabyte of data, the server is only going to read the first byte as the request body, and the rest will be a new request…

Can you put a note in the post about 100-continue, so people who don’t read comments aren’t led astray?

What I missed in Section 14.20 of RFC 2616 was this: “The server MUST respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with the request, some other 4xx status.”

Furthermore, Section 8.2.3 states: “Upon receiving a request which includes an Expect request-header field with the ‘100-continue’ expectation, an origin server MUST either respond with 100 (Continue) status and continue to read from the input stream, or respond with a final status code.”

So, it seems the problem is that Ruby and Richardson got it wrong in RESTful Web Services when they say: “If the answer is no, the server sends a status code of 417 (‘Expectation Failed’). The answer might be no because [...] 500 MB is just too big” (pg. 250).

> Be aware that the Content-Length header cannot be trusted.

I say this because Content-Length header can be spoofed easily. Someone can create a client to post arbitrary data to your service. If, for example, you only want to allow 50 MB uploads, and some malicious user wants to post something that’s 100 MB, they can set the Content-Length header to 50 MB and put however much data they wish in the entity body. So, you can’t necessarily take the Content-Length at face value; you should also validate that the content of the entity body is not greater than the length you want to accept.

This is incorrect. 417 means that an Expect you sent is unsupported; for example, if you send “Expect: bacon”, and the server doesn’t support that, then it responds with 417. Responding with 417 because the request was going to be too large badly violates the spec.

The purpose of 100-continue is to give the server a chance to give an error to the client before it sends the request body, rather than after. If doing that required that all of those detailed 4xx/5xx errors were turned into an opaque 417 and useless, plain language errors in the body, it would be useless.

> For the specific example of uploading large files, what do you think about returning 413 (Request Entity Too Large)?

This is the correct behavior.

> Be aware that the Content-Length header cannot be trusted.

I’m not sure what this means. Except for chunked connections, Content-Length must be trusted, or you won’t be able to tell where a request/response body ends.

I was wondering if there was a response status to allow a large file to be “served” in parts and in just one response?

I need a way to do this and I’d be grateful if the pedant offers succor

thanks!

header(‘HTTP/1.1 100 Continue’);

If you are building a client application and need to check for the 100 Continue and other headers in a response received from the server, you can you curl, fsockopen, or something like Zend_Http.

Be aware that the Content-Length header cannot be trusted. The value it contains should only be considered for informational purposes and may not be the actual size of the uploaded file. However, with a request containing an Expect: 100-continue header, there won’t be a file uploaded, so you have only the Content-Length header to go by for determining whether or not to tell the client to continue sending the full request.

They seem so hidden and untouchable, and you just want to use the standard 300/404/500…

The uses for some of them are very intriguing, and at least this one, 100, can significantly reduce overhead… instead of sending that 100mb file each time, then verifying details.. you can now verify before sending! GENIUS.