Checking http implementation

[trikko]

It seems that some frameworks are just build to win the benchmark but they are not really usable.

I think we should test for example the frameworks against invalid or malformed requests in many ways.

But even valid requests seem not correctly handled by many frameworks.

For example: is the "expect" header handled? If you post a file with curl, it sends an "expect" header and wait for server to send a 100-continue reply before sending the file body.

Or also: what if I send many requests together without waiting the reply from server ("http pipeline") or if I send a request in separated fragments like "GE" (sleep) "T / HTT" (sleep) "P/1.1" etc.

What if client post more data than declared in "content-lenght"?

[waghanza]

It will be very helpful if you list what is expected, and seems weird in some frameworks.

I can add some tests and start some modification on some implementations

[trikko]

There are numerous tests we can perform. I would start with some basic checks to ensure that we have a functioning server.

For instance, requests that begin with lines like the following should return a "400 Bad Request" response:

FAKE / HTTP/1.1
GETTT / HTTP/1.1
GET / HTTP/1.3
GET / HTTP/5.1
BLAH

Every HTTP/1.1 request must include a "Host" header; otherwise, it is considered a bad request.

The following request instead should return a 400 Bad Request or a HTTP/1.0 response:

GET / HTTP/1.0

I would also verify if some basic headers are parsed correctly. For example:

• Expect: 100-continue: If an HTTP/1.1 client receives this with a POST method, it should reply with a 100 Continue or 417 Expectation Failed.
• Both Connection: keep-alive and Connection: close must be supported.
• Without a Connection header, it defaults to keep-alive for HTTP/1.1 and close for HTTP/1.0, and the server must respond accordingly.
• What happens if I send Connection: blah?
• What happens if I send a header without a value like X-header:?
• Header fields are case-insensitive. So, both connection: close and CONnecTION: close should work.
• Content-Length must be parsed to read the exact amount of data from the client. Any extra data belongs to the next request in the pipeline (if the connection is keep-alive. If the connection is close, it's a bad request).
• What happens if I send Content-Length: -5?

I would also test pipelining, which involves sending multiple requests at once (with HTTP/1.1 and Connection: keep-alive) without waiting for the server's reply. The server must reply in the same order as the requests were received.

There are also other desirable behaviors to test. For example, what happens if a client opens a connection and doesn’t send any data? After a while, I think the connection should be closed to avoid occupying resources. The same goes for keep-alive: there should be a timeout after which the connection is interrupted if no more requests are received.

And so on...

[cyrusmsk]

Found this tool on GH. Could be useful for testing probably https://github.com/Orange-OpenSource/hurl