Re: Various fnord patches

Thus spake [email protected] ([email protected]):
> 1. Incomplete redirect response

> fnord constructs redirect responses like this:

> HTTP/1.0 301 Go Away
> Connection: close
> Location: <target>

> In particular, it does not set a Content-Length header. Normally, this is not
> a problem, because fnord exits after sending the response, causing the
> connection to shut down.

> However, when fnord is running with ucspi-ssl, fnord exiting doesn't cause
> the connection to close, causing the client to wait indefinitely for the
> response body. I don't know if that's a bug in ucspi-ssl, but it can be
> easily fixed in fnord by adding a "Content-Length: 0" header. Which is
> what my patch does.

This is a bug in ucspi-ssl.  Adding the header does no harm, so I'll do
it anyway.


> 2. Missing sanitation of request headers

Ouch.  Fixed in CVS.

> 3. Missing mime-type

> fnord doesn't recognise .ico files. No big deal - but my girlfriend wants
> a favicon.ico on her web site, so I've added a mime-type for it.

OK.

> 4. Redirect with slash on directory request

> Maybe fnord doesn't do this on purpose, but I like it simply because it
> is convenient:

Maybe I'll make this configurable in a future version, but not now :-)

> 5. Logging in case of Encoding: gzip

I do it like this on purpose, so you can see how many bytes you are
saving through gzip content encoding.

> 6. Another potential request smuggling problem

> While reading the request fnord will read up to MAXHEADERLEN - 5 bytes
> from its input in a single read() call. The buffer is then checked if it
> contains an empty line, and if so, the buffer content before the empty
> line is treated as an HTTP request. So far so good.

> If it's a keep-alive connection, the rest of the buffer is discarded before
> fnord tries reading the next request. Not good.

> I found the problem when I tried reproducing problem #2 above by piping
> an input file containing two requests into fnord. fnord always only sent
> one response. In practice this may not be a problem, unless a client tries
> really hard to pipeline requests.

> I haven't patched this one, but I think it should be.

fnord does not support pipelining.  AFAIK this is perfectly legal.
gatling does support pipelining, in case you must have it, but in
practice it does not help a lot, since clients cannot simply assume the
server supports it and thus noone uses it.

Felix