Re: A fnord fork (a fnork?)

On 2/16/2012, "Felix von Leitner" <[email protected]> wrote:

>>   Add all patches from (defunct) Debian package
>
>Don't know about those.

Oh, I thought Gerrit Pape was sending patches upstream.  If not, this
explains quite a bit.

Fnord is no longer built in Debian, but the patches are available here:

   http://ftp.de.debian.org/debian/pool/main/f/fnord/fnord_1.10-4.diff.gz

>>   Replace libowfat with libc
>>   Replace buffer_1 and buffer_2 with stdio
>
>I'll certainly not pull those changes in.

I didn't expect you to :)

>>   Fix segfault with directory listing of /
>
>Wait, what?

If you compile fnord 1.10 with directory indexing, and don't have
index.html at root, then fnord segfaults when you ask for /.  It is
because of this line in handledirlist:

      if (nurl[nl-1]!='/') return;

When the path is "/", nl is 0 here.

This is not an exploitable segfault.

>>   Replace compile-time options with command-line ones
>
>Code you don't have in the binary can't have bugs and can't be
>accidentally activated.

Agreed.  For my purposes, though (an embedded build), it takes less
storage space to have a single binary with command-line arguments.

>>   Add regression test suite
>>   Fix if-modified-since date parsing
>
>What's wrong with it?

Time zone handling, apparently.  Here is the (manually reformatted) patch
Debian used.  I replaced it with code from mathopd in my fork, because
at the time I encountered the bug I didn't have the time to debug the
problem.

This patch will trigger uclibc (and probably dietlibc) to parse various
timezone files, incurring maybe 7-9 additional system calls.  glibc does
these syscalls anyway with the call to gmtime to send the Last-Modified
header field, so there's no added penalty.  You are already paying a
big penalty just by using glibc in the first place :)

diff --git a/httpd.c b/httpd.c
index 432f8b4..6a15e6c 100644
--- a/httpd.c
+++ b/httpd.c
@@ -835,7 +835,7 @@ static time_t parsedate(const char*c) {
   if (parsetime(c,&x)) return (time_t)-1;
 done:
   x.tm_wday=x.tm_yday=x.tm_isdst=0;
-  return mktime(&x);
+  return mktime(&x)-timezone;
 }

 static struct stat st;
@@ -1289,6 +1289,10 @@ int main(int argc,char *argv[],const char *const
*envp) {
   int len;  In practicethere isn't much of a change.

   int in;

+  struct timezone tz;
+  gettimeofday(0, &tz);
+  timezone=tz.tz_minuteswest*60L;
+
   if (argc>1) chdir(argv[1]);

 #ifdef CHROOT

>>   Make text content-types use charset=UTF-8
>
>I would actually consider it a bug if you do that.

Perhaps for a general-purpose httpd it is still the case that no charset
is the correct default so I can't argue this point.

>>   Makefile no longer overrides CC and CPP from parent makes
>
>What parent makes?
>If you want to integrate fnord into some larger build system, then ...
>well integrate it.  That's why it's called integration.  Because you
>might have to touch it.

Yes, absolutely.  I felt it important that people know what to expect
from my fork so I documented this.  I am cross-compiling fnord to a
different architecture and so need to specify a special compiler and
linker.

>>   Don't send Content-type if there's no content
>
>Why?

It confused some software I was using at one point.  I don't think it
was a browser, though.  It may have been libcurl or busybox wget.

>> I'm currently working on a problem with CGI end-of-header parsing that I
>> discovered with the regression test suite on different platforms.
>
>Please elaborate?

One of my test CGIs, when run on Arch Linux, is resulting in fnord
sending "[HEADER]...\r\n\n", instead of the "\r\n\r\n" it
should send.  Debian's /bin/sh is not doing this.  I haven't figured
out exactly why yet but I suspect it is because fnord expects the entire
header block to come in with a single read() from the child process's
stdout, and this version of the shell is writing only one line at a time.

>Fork away if you want to, but if you actually discovered bugs, then I
>would like to hear about them.

I will of course mail the list with any additional problems I encounter.

I will give my fork a new name.  I had incorrectly assumed that fnord was
no longer being maintained.

>I don't get why you would want to remove libowfat, to be honest.  That
>and dietlibc are what makes fnord viable as a web server in practice.
>Because the static binary is so tiny.

I removed dietlibc because I am cross-compiling to a uclibc system on a
different architecture.

I removed libowfat because it was confusing my interns.  That's not a
good reason, but it's the only one I have.

These library changes should not be compelling reasons for anyone to
switch from fnord.  I have not benchmarked my fork but expect it to
perform about the same or slower than fnord 1.10.