2 ms·
There are quirkier things: • Content-Length is defined to be a number, but it actually may be a comma-separated list. This is due to a rule that repeated heade
by pornel 4y ago
There are quirkier things:
• Content-Length is defined to be a number, but it actually may be a comma-separated list. This is due to a rule that repeated headers can be merged into one header with a list, and buggy software that happened to output multiple Content-Length headers that subsequently got merged.
• If you want to implement a crawler or proxy that works with all real-world HTTP servers, then no matter how broken and invalid responses you get, if Internet Explorer accepted them (and it accepted pretty much everything), then you have to make sense of them too.
• HTTP/1 is vulnerable to request smuggling. There can be multiple HTTP messages on the same TCP/IP connection sent one after another. If the sender and recipient don't parse the length of the first message in exactly the same way, they'll get out of sync and the recipient will start interpreting message body (often attacker-controlled) as subsequent HTTP requests/responses.
• Expect + 100 Continue allows clients to start uploading a file only if the server gives it a green light (client sends headers and waits for status 100 response). However, this part of the protocol is kinda buggy, because the client has no way of knowing if the server supports status 100. If the client gives up waiting for status 100 and falls back to sending the body anyway, there's a risk of a race condition when server denied the upload, but still received it. In that case the server will parse body as a new HTTP request.
- hnov 4y agoAs much as I'll miss being able to type raw HTTP into an nc/telnet/openssl s_client when H/1.1 support is dropped, these are all caused by HTTP originally being a simple, textual protocol that got thrust into supporting connection reuse, "flow control" and a bunch of other stuff. All solved by H/2 and beyond.