annoying tux bug
Steve Simitzis <[email protected]>
| Newsgroups | gmane.network.tux |
|---|---|
| Message-ID | <[email protected]> |
hello.
i'm running a module which depends on the If-Modified-Since header,
as sent by the browser. i am calling the module for a single MIME
type, rather than the whole lot. the If-Modified-Since header
determines whether or not the filename (as specified by a query
string to the module) should be served to the browser. it's a
very simple cache mechanism. (and yes, the module does other
things, but i needed to add simple caching.)
so here's the problem.
everything is fine and good, unless the If-Modified-Since time is
newer than the mtime of the root-owned file under the doc root.
in which case, tux bypasses my module and returns a 304 Not Modified
to the browser.
this is very frustrating, and unnecessary. why shouldn't tux send
everything to my module, and let the module sort out whether or
not it's going to ignore the If-Modified-Since header?
i noticed that there's a hint of the correct behavior already:
from proto_http.c: (comments mine)
/* send all requests to a userspace module? */
if (tux_all_userspace) {
tcapi_template_t *tcapi = get_first_usermodule();
if (tcapi) {
req->usermode = 1;
req->usermodule_idx = tcapi->userspace_id;
goto usermode;
}
}
/* otherwise, compare If-Modified-Since, etc */
missed = lookup_url(req, lookup_flag);
but, only in the case that all_userspace is set. this, to me, seems
like a bug, because the behavior is inconsistent.
help?
--
steve simitzis : /sim' - i - jees/
pala : saturn5 productions
www.steve.org : 415.282.9979
hath the daemon spawn no fire?