Now it should work. It doesn't make much sense to tweak the default
mime-type, given octet-stream is the default and there are
no real alternatives which would make sense.
Thanks Hiltjo and sin!
For a server, a solid logging-facility is very important.
Reading quark's logs isn't very pleasant, given it prints out
more vocabulary than necessary.
This patch fixes this problem by bringing the logs into a
readable and even parsable form:
-timestamp- -keyword- [-message-]
Keywords now take the role as carriers of information.
Instead of writing that we're redirecting, we just
print a line with a status 304 and what the requested
location was. The subsequent 200-response shows the
redirected location.
This also makes clearer what happens in the background.
The tab-separation allows easy parsing.
You can't handle SIGKILL. Given we have control over which
signals are passed to the sighandler, it's enough to catch SIGCHLD
and do standard behaviour than building a big switch for that.
This is the first step for unifying the return-values inside quark.
1: error
0: success
-1: not found (non-fatal, for instance, if you run getresentry
on a non-essential entry)
Instead of providing a function for each entry-type, use a small
static lookup-table and one function to rule them all.
In the future, in case the list grows, we might think about
implementing it with a small hash-lookup, but currently,
it's easy enough synchronizing the enum and the array.
While at it, improve the logic in the code itself
by using logical OR's instead of AND's.
On each request send "last-modified" header with the modification time of
each file. the client will store this field and send it on the next
request(s). On the server check the "if-modified-since" field with the
modified date sent by the client, depending on this send all the data or
the "304 not modified" http status.
CAVEAT: it is assumed the exact field will be send by the client, no date/time
conversion is done for simplicity sake, as far as that's possible with http ;)
