durusmail: quixote-users: Overlaying a static directory
Overlaying a static directory
2005-04-11
2005-04-12
2005-04-12
2005-04-12
2005-04-13
2005-04-13
2005-04-14
2005-04-14
2005-04-14
2005-04-14
2005-04-14
2005-04-14
2005-04-14
2005-04-14
2005-04-14
2005-04-14
David Binger (3 parts)
2005-04-14
2005-04-14
2005-04-13
2005-04-14
2005-04-14
2005-04-13
SCGI util.
2005-04-12
2005-04-13
2005-04-13
2005-04-13
2005-04-13
Overlaying a static directory
David Binger
2005-04-14
On Apr 14, 2005, at 10:12 AM, Ryan Tomayko wrote:
> I'm not exactly sure where the problem is occurring. It could be an on
> the SCGI side or the Apache side. I don't understand why apache
> wouldn't just pass that header through to the client as opaque data to
> be honest.

I don't either.  It looks, though, like Apache does anticipate and
correct Last-Modified values
that are in the future.  Also, I think there is a Premature end of
script headers message for
this in the Apache log.  Is there something in the value of the last
modified header that
might cause Apache to have trouble parsing the line?


A clue from apache 1, util_script.c ap_scan_script_header_err_core():
>     /*
>      * If the script gave us a Last-Modified header, we can't just
>      * pass it on blindly because of restrictions on future values.
>      */
>     else if (!strcasecmp(w, "Last-Modified")) {
>         time_t mtime = ap_parseHTTPdate(l);
>
>         ap_update_mtime(r, mtime);
>         ap_set_last_modified(r);
>     }
>

 From http_protocol.c:

> /*
>  * This function sets the Last-Modified output header field to the
> value
>  * of the mtime field in the request structure - rationalized to keep
> it from
>  * being in the future.
>  */
> API_EXPORT(void) ap_set_last_modified(request_rec *r)
> {
>     time_t mod_time = ap_rationalize_mtime(r, r->mtime);
>
>     ap_table_setn(r->headers_out, "Last-Modified",
>               ap_gm_timestr_822(r->pool, mod_time));
> }
>

also in http_protocol.c:
> API_EXPORT(time_t) ap_rationalize_mtime(request_rec *r, time_t mtime)
> {
>     time_t now;
>
>     /* For all static responses, it's almost certain that the file was
>      * last modified before the beginning of the request.  So there's
>      * no reason to call time(NULL) again.  But if the response has
> been
>      * created on demand, then it might be newer than the time the
> request
>      * started.  In this event we really have to call time(NULL) again
>      * so that we can give the clients the most accurate
> Last-Modified.  If we
>      * were given a time in the future, we return the current time -
> the
>      * Last-Modified can't be in the future.
>      */
>     now = (mtime < r->request_time) ? r->request_time : time(NULL);
>     return (mtime > now) ? now : mtime;
> }


reply