Ticket #197 (new defect)
Opened 4 years ago
paste.httpserver doesn't take into account a common browser bug
| Reported by: | jnelson | Owned by: | ianb |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.4.1 |
| Component: | paste | Version: | svn-trunk |
| Severity: | normal | Keywords: | |
| Cc: |
Description
There is a very common browser bug wherein for POST requests most (all?) browsers lie about the content-length they actually send.
Specifically, let us assume an actual content-length of 7 bytes. On the wire, you will actually see 9 bytes - the 7 actual bytes plus CRLF. Often these CRLF are sent as a separate packet, and depending on your network and a whole host of timing issues, the CRLF may or may not make it into the application's read buffer before it is read. If those two bytes are NOT read and the application (httpserver) closes the connection, the TCP stack will sent a TCP RESET. Unfortunately, due to the current code in the paste.httpserver module, this means that the request went through, a response was generated, but the response only sometimes gets through to the browser (again, due to timing issues too numerous to list). I spent several hours debugging this until I remember the issue. It's easily google-able, and most http servers work around it by reading a bit beyond the actual content-length and throwing it out - paste.httpserver does not do that and as a result doing development with it can be (occasionally) pretty frustrating.
It's also not terribly hard to fix, although just like the Apache, Boa, and other solutions it's a bit of a hack.
