fteproxy server's response to malformed messages
cypherpunks suggests that fteproxy, when using an HTTP regex, should tolerate a range of HTTP headers. Specifically, an fteproxy server when using HTTP will terminate the connection, if the following is submitted:
GET /<encoded_data> HTTP/1.1\r\n Host: tpo.org\r\n User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0\r\n Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n Accept-Language: en-us,en;q=0.5\r\n Accept-Encoding: gzip, deflate\r\n Connection: keep-alive\r\n \r\n
It turns out that this is a complex issue to solve in general, as one solution we could allow custom error handlers in fteproxy that are activated under certain cases.
As a step towards this, we should probably distinguish between the following two cases:
- The server receives a message that is in the language specified by the regex, but is malformed.
- The server receives a message that is NOT in the language specified by the regex, and is, by definition, malformed.