Re: t_cmp oddities
Geoffrey Young wrote: I understand that your patch proposes to introduce: use Apache::TestUtil qw(:testmore); use Test::More; correct? Apache::Test, not TestUtil, but yes. argh, right, which makes my second part of the answer mostly irrelevant since I thought you were talking about TestUtil. There are two things: 1. :tesmore imports has nothing to do with Test::More, so that tag is very confusing. How about fixing import() instead and use a special optional first argument: use Apache::TestUtil '-withtestmore'; use Test::More; or similar? testmore, withtestmore, whatever you want to call it. as for the '-foo' versus 'foo' stuff one is more standard than the other but however you prefer is fine. whichever is fine with me. Though please explain where did you take that standard from? I think most modules follow the followinig import convention: - a word 'foo' usually means symbol and you'd expect to be able to use it in a form of ([EMAIL PROTECTED])foo. - a tag ':foo' means, import a group of tags. - a string '-foo' means, tell import to do something, i.e. a command. And I prefer 'withtestmore', to imply: don't not import symbols exportable by Test::More. 2. Apache::TestUtil's ok, skip and plan aren't compatible with Test::More's one, so I'm not sure what do you achieve with this patch. what you get is all of Apache::Test except ok, skip, and plan. those are the methods that get redefined warnings and cause problems when you try to mix the two modules (especially with fatal warnings). in particular Test::More requires you to use Test::More::plan() or else each of its methods (say, is_deeply()) complains about not having called Test::More::plan(). That makes sense. IMHO, users wanting to only use Apache::TestUtil's certain functions while using Test::More should simply import only those functions. Problem solved. for the most part I (and others I have talked to) want to use just about all the methods from each: all the have_* functions from Apache::Test as well as the like() functions from Test::More. if you wanted that, you would need to hand-type 17 import methods from Apache::Test. this eliminates the need for that and allows for a more idiomatic usage. simply use Apache::TestUtil qw(:testmore); use Test::More; gives you everything from Apache::Test except those methods that collide with Test::More. you are then free to use Apache::TestUtil functions in your tests while keeping with Test::More's familar plan() and ok() interface. See you are confused just as I do :0) It's Apache::Test, not Apache::TestUtil that you are after. It was just a wrong thread to disscuss this, my head was absorbed inside TestUtil. but whatever. I'm just trying to make userspace easier. geoff++ __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: error during make all
You shouldn't have to run buildconf. Start from a clean tarball again and just run ./configure with your args and then make. -aaron On Apr 4, 2004, at 9:41 PM, Navneetha wrote: am am new to apache flood.i have downloaded the copy of flood .after successful download i am able to successfully execute ./buildconf and ./configure --disable-shared .
Re: Apache 1.3.30 release candidate tarball available for testing
Jim Jagielski wrote: At: http://httpd.apache.org/dev/dist/ Works great on SCO OpenServer 5.0.7 and UnixWare 7.1.3. Kean
Re: cvs commit: httpd-2.0/modules/experimental util_ldap.c
[EMAIL PROTECTED] wrote:
bnicholes2004/03/31 14:56:08
Modified:modules/experimental util_ldap.c
Log:
Update the DN information associated with each LDAP connection after util_ldap_cache_checkuserid() rebinds the connection.
Revision ChangesPath
1.22 +12 -0 httpd-2.0/modules/experimental/util_ldap.c
Index: util_ldap.c
===
RCS file: /home/cvs/httpd-2.0/modules/experimental/util_ldap.c,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- util_ldap.c 9 Feb 2004 20:29:18 - 1.21
+++ util_ldap.c 31 Mar 2004 22:56:08 - 1.22
@@ -844,6 +844,18 @@
ldap_msgfree(res);
return result;
}
+else {
+/*
+ * Since we just bound the connection to the authenticating user id, update the
+ * ldc-binddn and ldc-bindpw to reflect the change and also to allow the next
+ * call to util_ldap_connection_open() to handle the connection reuse appropriately.
+ * Otherwise the next time that this connection is reused, it will indicate that
+ * it is bound to the original user id specified ldc-binddn when in fact it is
+ * bound to a completely different user id.
+ */
+ldc-binddn = apr_pstrdup(st-pool, *binddn);
+ldc-bindpw = apr_pstrdup(st-pool, bindpw);
isn't st-pool pconf? (or maybe I'm having trouble tracking ldc and st ;) )
can binddn and bindpw be repeatedly replaced with new values, creating
uncontrolled growth of pconf?
Re: Apache 1.3.30 release candidate tarball available for testing
Tests out OK on IBM's TPF platform. -David Jim Jagielski [EMAIL PROTECTED] To 04/12/2004 12:48 [EMAIL PROTECTED] PM cc [EMAIL PROTECTED] Subject Please respond to Apache 1.3.30 release candidate devtarball available for testing At: http://httpd.apache.org/dev/dist/ Please check it out in anticipation for a release tomorrow or so.
1.3.3x digest/nonce issue
There is a known bug/issue in the current implementation of mod_digest regarding the nonce. I am looking to have this plugged for our next 1.3 release. There are 2 suggested patches, which I will post under separate Emails. I will also adjust STATUS to reflect these 2 potential patches. PLEASE look these over! I would still like to get a 1.3 release out soon. My expectation is that we will toss 1.3.30...
[PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
On Apr 13, 2004, at 11:13 AM, Jim Jagielski wrote:
There is a known bug/issue in the current implementation
of mod_digest regarding the nonce. I am looking to
have this plugged for our next 1.3 release.
There are 2 suggested patches, which I will post under
separate Emails. I will also adjust STATUS to reflect
these 2 potential patches.
PLEASE look these over! I would still like to get a
1.3 release out soon. My expectation is that we
will toss 1.3.30...
Candidate patch #1:
Index: src/main/http_core.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v
retrieving revision 1.331
diff -u -r1.331 http_core.c
--- src/main/http_core.c16 Feb 2004 22:29:33 - 1.331
+++ src/main/http_core.c17 Mar 2004 14:02:15 -
@@ -193,6 +193,9 @@
if (new-ap_auth_name) {
conf-ap_auth_name = new-ap_auth_name;
}
+if (new-ap_auth_nonce) {
+conf-ap_auth_nonce = new-ap_auth_nonce;
+}
if (new-ap_requires) {
conf-ap_requires = new-ap_requires;
}
@@ -534,6 +537,32 @@
return conf-ap_auth_name;
}
+API_EXPORT(const char *) ap_auth_nonce(request_rec *r)
+{
+core_dir_config *conf;
+conf = (core_dir_config *)ap_get_module_config(r-per_dir_config,
+ core_module);
+if (conf-ap_auth_nonce)
+ return conf-ap_auth_nonce;
+
+/* Ideally we'd want to mix in some per-directory style
+ * information; as we are likely to want to detect replay
+ * across those boundaries and some randomness. But that
+ * is harder due to the adhoc nature of .htaccess memory
+ * structures, restarts and forks.
+ *
+ * But then again - you should use AuthNonce in your config
+ * file if you care. So the adhoc value should do.
+ */
+return ap_psprintf(r-pool,%lu%lu%lu%lu%lu%s,
+ *(unsigned long *)((r-connection-local_addr).sin_addr ),
+ *(unsigned long *)ap_user_name,
+ *(unsigned long *)ap_listeners,
+ *(unsigned long *)ap_server_argv0,
+ *(unsigned long *)ap_pid_fname,
+ WHAT_THE_HECK_GOES_HERE?);
+}
+
API_EXPORT(const char *) ap_default_type(request_rec *r)
{
core_dir_config *conf;
@@ -2781,6 +2810,28 @@
return NULL;
}
+/*
+ * Load an authorisation nonce into our location configuration, and
+ * force it to be in the 0-9/A-Z realm.
+ */
+static const char *set_authnonce (cmd_parms *cmd, void *mconfig, char
*word1)
+{
+core_dir_config *aconfig = (core_dir_config *)mconfig;
+int i;
+
+aconfig-ap_auth_nonce = ap_escape_quotes(cmd-pool, word1);
+
+if (strlen(aconfig-ap_auth_nonce) 510)
+ return AuthNonce length limited to 510 chars for browser
compatibility;
+
+for(i=0;istrlen(aconfig-ap_auth_nonce );i++)
+ if (!ap_isalnum(aconfig-ap_auth_nonce [i]))
+ return AuthNonce limited to 0-9 and A-Z range for browser
compatibility;
+
+return NULL;
+}
+
+
#ifdef _OSD_POSIX /* BS2000 Logon Passwd file */
static const char *set_bs2000_account(cmd_parms *cmd, void *dummy,
char *name)
{
@@ -3395,6 +3446,9 @@
An HTTP authorization type (e.g., \Basic\) },
{ AuthName, set_authname, NULL, OR_AUTHCFG, TAKE1,
The authentication realm (e.g. \Members Only\) },
+{ AuthNonce, set_authnonce, NULL, OR_AUTHCFG, TAKE1,
+ An authentication token which should be different for each logical
realm. \
+ A random value or the servers IP may be a good choise.\n },
{ Require, require, NULL, OR_AUTHCFG, RAW_ARGS,
Selects which authenticated users or groups may access a protected
space },
{ Satisfy, satisfy, NULL, OR_AUTHCFG, TAKE1,
Index: src/main/http_protocol.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_protocol.c,v
retrieving revision 1.332
diff -u -r1.332 http_protocol.c
--- src/main/http_protocol.c16 Feb 2004 22:29:33 - 1.332
+++ src/main/http_protocol.c17 Mar 2004 14:02:17 -
@@ -33,6 +33,7 @@
#include util_date.h /* For parseHTTPdate and BAD_DATE */
#include stdarg.h
#include http_conf_globals.h
+#include util_md5.h /* For digestAuth */
#define SET_BYTES_SENT(r) \
do { if (r-sent_bodyct) \
@@ -1348,11 +1349,25 @@
API_EXPORT(void) ap_note_digest_auth_failure(request_rec *r)
{
+/* We need to create a nonce which:
+ * a) changes all the time (see r-request_time)
+ *below and
+ * b) of which we can verify that it is our own
+ *fairly easily when it comes to veryfing
+ *the digest coming back in the response.
+ * c) and which as a whole should not
+ *be unlikely to be in use anywhere else.
+ */
+char * nonce_prefix = ap_md5(r-pool,
+ (unsigned char *)
+ ap_psprintf(r-pool, %s%lu,
+ ap_auth_nonce(r), r-request_time));
+
ap_table_setn(r-err_headers_out,
r-proxyreq == STD_PROXY ?
[PATCH] Candidate 2: Re: 1.3.3x digest/nonce issue
On Apr 13, 2004, at 11:13 AM, Jim Jagielski wrote:
There is a known bug/issue in the current implementation
of mod_digest regarding the nonce. I am looking to
have this plugged for our next 1.3 release.
There are 2 suggested patches, which I will post under
separate Emails. I will also adjust STATUS to reflect
these 2 potential patches.
PLEASE look these over! I would still like to get a
1.3 release out soon. My expectation is that we
will toss 1.3.30...
Candidate patch #2
Index: src/ApacheCore.def
===
RCS file: /home/cvs/apache-1.3/src/ApacheCore.def,v
retrieving revision 1.35
diff -u -r1.35 ApacheCore.def
--- src/ApacheCore.def 18 Jun 2002 04:19:46 - 1.35
+++ src/ApacheCore.def 18 Dec 2003 21:25:49 -
@@ -447,3 +447,4 @@
ap_getline @439
ap_get_chunk_size @440
ap_escape_logitem @441
+ap_auth_nonce @442
Index: src/ApacheCoreOS2.def
===
RCS file: /home/cvs/apache-1.3/src/ApacheCoreOS2.def,v
retrieving revision 1.13
diff -u -r1.13 ApacheCoreOS2.def
--- src/ApacheCoreOS2.def 22 May 2003 09:45:28 - 1.13
+++ src/ApacheCoreOS2.def 18 Dec 2003 21:25:50 -
@@ -430,3 +430,4 @@
ap_escape_logitem @441
ap_popenf_ex @442
ap_psocket_ex @443
+ ap_auth_nonce @444
Index: src/CHANGES
===
RCS file: /home/cvs/apache-1.3/src/CHANGES,v
retrieving revision 1.1914
diff -u -r1.1914 CHANGES
--- src/CHANGES 14 Dec 2003 18:16:49 - 1.1914
+++ src/CHANGES 18 Dec 2003 21:25:56 -
@@ -1,5 +1,11 @@
Changes with Apache 1.3.30
+ *) SECURITY: CAN-2003-0987 (cve.mitre.org)
+ Verification as to whether the nonce returned in the client
response
+ is one we issued ourselves by means of a AuthNonce secret exposed
as an
+ md5(). See mod_digest documentation for more details. The
experimental
+ mod_auth_digest.c does not have this issue. [Dirk-Willem van
Gulik]
+
*) Fix mod_include's expression parser to recognize strings correctly
even if they start with an escaped token. [André Malo]
Index: src/include/ap_mmn.h
===
RCS file: /home/cvs/apache-1.3/src/include/ap_mmn.h,v
retrieving revision 1.65
diff -u -r1.65 ap_mmn.h
--- src/include/ap_mmn.h14 Dec 2003 18:16:49 - 1.65
+++ src/include/ap_mmn.h18 Dec 2003 21:25:56 -
@@ -244,6 +244,8 @@
*ap_popenf_ex() and ap_psocket_ex().
* 19990320.15 - ap_is_recursion_limit_exceeded()
* 19990320.16 - ap_escape_errorlog_item()
+ * 19990320.17 - ap_auth_nonce() and ap_auth_nonce added
+ *in core_dir_config.
*/
#define MODULE_MAGIC_COOKIE 0x41503133UL /* AP13 */
Index: src/include/http_core.h
===
RCS file: /home/cvs/apache-1.3/src/include/http_core.h,v
retrieving revision 1.71
diff -u -r1.71 http_core.h
--- src/include/http_core.h 7 Jul 2003 00:34:09 - 1.71
+++ src/include/http_core.h 18 Dec 2003 21:25:56 -
@@ -162,6 +162,7 @@
API_EXPORT(const char *) ap_auth_type (request_rec *);
API_EXPORT(const char *) ap_auth_name (request_rec *);
+API_EXPORT(const char *) ap_auth_nonce (request_rec *);
API_EXPORT(int) ap_satisfies (request_rec *r);
API_EXPORT(const array_header *) ap_requires (request_rec *);
@@ -312,6 +312,9 @@
*/
ap_flag_e cgi_command_args;
+/* Digest auth. */
+char *ap_auth_nonce;
+
} core_dir_config;
/* Per-server core configuration */
Index: src/main/http_core.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v
retrieving revision 1.327
diff -u -r1.327 http_core.c
--- src/main/http_core.c17 Nov 2003 17:14:53 - 1.327
+++ src/main/http_core.c18 Dec 2003 21:25:58 -
@@ -236,6 +236,9 @@
if (new-ap_auth_name) {
conf-ap_auth_name = new-ap_auth_name;
}
+if (new-ap_auth_nonce) {
+conf-ap_auth_nonce = new-ap_auth_nonce;
+}
if (new-ap_requires) {
conf-ap_requires = new-ap_requires;
}
@@ -577,6 +580,29 @@
return conf-ap_auth_name;
}
+API_EXPORT(const char *) ap_auth_nonce(request_rec *r)
+{
+core_dir_config *conf;
+conf = (core_dir_config *)ap_get_module_config(r-per_dir_config,
+ core_module);
+if (conf-ap_auth_nonce)
+ return conf-ap_auth_nonce;
+
+/* Ideally we'd want to mix in some per-directory style
+ * information; as we are likely to want to detect replay
+ * across those boundaries and some randomness. But that
+ * is harder due to the adhoc nature of .htaccess memory
+ * structures, restarts and forks.
+ *
+ * But then again - you
RE: mod_cgi and apr_setup_signal_thread
You're partially correct. Here's whatz happening: worker.c: child_main() invokes apr_setup_signal_thread() signals.c: apr_setup_signal_thread() - sigfillset(sig_mask); remove_sync_sigs(sig_mask); sigprocmask(SIG_SETMASK, sig_mask, NULL) - Thus disabling the delivery of async signals to the process mod_cgi comes along, forks a child process and happily inherits the signal mask from the parent (the only thing apr_proc_create() does is to change SIGCHLD to default behaviour). -Madhu -Original Message- From: Jeff Trawick [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 13, 2004 4:55 AM To: [EMAIL PROTECTED] Subject: Re: mod_cgi and apr_setup_signal_thread Mathihalli, Madhusudan wrote: I'm using the worker MPM for both mod_cgi and mod_cgid. I don't see any httpd 2.0/apr 0.9 code which manipulates SIGALRM. Can you give me a pointer?
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
Jim Jagielski wrote: On Apr 13, 2004, at 11:13 AM, Jim Jagielski wrote: There is a known bug/issue in the current implementation of mod_digest regarding the nonce. I am looking to have this plugged for our next 1.3 release. There are 2 suggested patches, which I will post under separate Emails. I will also adjust STATUS to reflect these 2 potential patches. PLEASE look these over! I would still like to get a 1.3 release out soon. My expectation is that we will toss 1.3.30... Candidate patch #1: This was my patch to an earlier patch to address some build issues and point out a run-time problem with a sprintf call I guess I need to go through patch 2 and verify that everything was addressed, and/or point out the missing pieces (after I get my tax returns finished and in the mail).
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
Jeff Trawick wrote: Candidate patch #1: This was my patch to an earlier patch to address some build issues and point out a run-time problem with a sprintf call I guess I need to go through patch 2 and verify that everything was addressed, and/or point out the missing pieces (after I get my tax returns finished and in the mail). It looks like the other suggested patch incorporates some of your comments, but not all. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: cvs commit: httpd-2.0/modules/experimental util_ldap.c
You are correct although it isn't as bad as it seems. There are
actually two types of caching going on here. There is the ldap
connection cache and the user credential cache. Because the user
credentials are cached, subsequent requests from the same user are not
actually authenticated directly against LDAP. util_ldap simply checks
it own cache to make sure that the user name and password are good. If
so, then it by passes the LDAP search. Therefore, the values for the
ldap binddn and bindpw would only be replaced when the cached user
credentials expire and a reauthentication requires a new ldap search.
But over time or if the user credential cache is disabled, this
could still be a problem so I have attached a patch that eliminates the
repeated allocations from the pconf pool. Please let me know if you see
any problems with this additional patch. I would like to get this
commited and backported soon.
Brad
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
[EMAIL PROTECTED] Tuesday, April 13, 2004 5:44:19 AM
[EMAIL PROTECTED] wrote:
bnicholes2004/03/31 14:56:08
Modified:modules/experimental util_ldap.c
Log:
Update the DN information associated with each LDAP connection
after util_ldap_cache_checkuserid() rebinds the connection.
Revision ChangesPath
1.22 +12 -0 httpd-2.0/modules/experimental/util_ldap.c
Index: util_ldap.c
===
RCS file: /home/cvs/httpd-2.0/modules/experimental/util_ldap.c,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- util_ldap.c 9 Feb 2004 20:29:18 - 1.21
+++ util_ldap.c 31 Mar 2004 22:56:08 - 1.22
@@ -844,6 +844,18 @@
ldap_msgfree(res);
return result;
}
+else {
+/*
+ * Since we just bound the connection to the
authenticating user id, update the
+ * ldc-binddn and ldc-bindpw to reflect the change and
also to allow the next
+ * call to util_ldap_connection_open() to handle the
connection reuse appropriately.
+ * Otherwise the next time that this connection is reused,
it will indicate that
+ * it is bound to the original user id specified
ldc-binddn when in fact it is
+ * bound to a completely different user id.
+ */
+ldc-binddn = apr_pstrdup(st-pool, *binddn);
+ldc-bindpw = apr_pstrdup(st-pool, bindpw);
isn't st-pool pconf? (or maybe I'm having trouble tracking ldc and st
;) )
can binddn and bindpw be repeatedly replaced with new values, creating
uncontrolled growth of pconf?
util_ldap.c.patch
Description: Binary data
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
Jim Jagielski wrote:
On Apr 13, 2004, at 11:13 AM, Jim Jagielski wrote:
static const char *set_bs2000_account(cmd_parms *cmd, void *dummy, char
*name)
{
@@ -3395,6 +3446,9 @@
An HTTP authorization type (e.g., \Basic\) },
{ AuthName, set_authname, NULL, OR_AUTHCFG, TAKE1,
The authentication realm (e.g. \Members Only\) },
+{ AuthNonce, set_authnonce, NULL, OR_AUTHCFG, TAKE1,
+ An authentication token which should be different for each logical
realm. \
+ A random value or the servers IP may be a good choise.\n },
Surely this advice is not good - this value (according to my reading) is
the only secret that prevents forgery of nonces. OTOH, its late, and I
may not be thinking clearly about this - in fact, I'm suspecting that
forgery of nonces is not an issue - the issue is using the same nonce in
different realms - but I'll send this anyway just so it gets discussed.
Also, this isn't really a nonce - the constructed value is - this is a
nonce seed, or something along those lines.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
I do have one question about this: Is anyone actually using mod_digest? I was under the impression that there doesn't exist any client that can interoperate with this module (as opposed to mod_auth_digest, which supports modern clients). If this is true, why don't we just delete the darn thing? Joshua.
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
Joshua Slive wrote: I do have one question about this: Is anyone actually using mod_digest? I was under the impression that there doesn't exist any client that can interoperate with this module (as opposed to mod_auth_digest, which supports modern clients). If this is true, why don't we just delete the darn thing? 1.3's mod_digest works with opera, mozilla, konquer, and a few others last time I checked. it does not work with msie, though, which I guess is the big reason it wasn't widely deployed. --Geoff
mod_ext_filter and last-modified header
It looks like mod_ext_filter sets the last-modified http header based on the mod time of the *filter* file and not the actual file represented by the URL. eg. the following filter is configured in httpd.conf ExtFilterDefine filter-name mode=output intype=text/html outtype=text/html \ cmd=/web_home/filters/filter.pl Directory /web_home/htdocs SetOutputFilter filter-name [etc...] now, if you try to get the following url: http://server/file.html the Last-Modified HTTP header seems to be set based on the timestamp on /web_home/filters/filter.pl and NOT on /web_home/htdocs/file.html i was hoping that this would be an easy fix for someone a lot more familiar with the code. i do understand that this may change the current behavior of existing apps that use mod_ext_filter... so, comments are welcomed... tia! craig
Re: mod_ext_filter and last-modified header
Craig Sebenik wrote: It looks like mod_ext_filter sets the last-modified http header based on the mod time of the *filter* file and not the actual file represented by the URL. the Last-Modified HTTP header seems to be set based on the timestamp on /web_home/filters/filter.pl and NOT on /web_home/htdocs/file.html I would hope it would be the newer of both, since both contribute to the freshness of the content, which is what is important. if you touch file.html do you get the newer timestamp? --Geoff
Re: mod_ext_filter and last-modified header
Quoting Geoffrey Young ([EMAIL PROTECTED]): Craig Sebenik wrote: It looks like mod_ext_filter sets the last-modified http header based on the mod time of the *filter* file and not the actual file represented by the URL. the Last-Modified HTTP header seems to be set based on the timestamp on /web_home/filters/filter.pl and NOT on /web_home/htdocs/file.html I would hope it would be the newer of both, since both contribute to the freshness of the content, which is what is important. if you touch file.html do you get the newer timestamp? my mistake. it looks like it works just the opposite of what i said. if i change the *code*, and NOT the file, then the last-modified is unchanged. i agree, it should be the newer of both. (fyi, the machines are in the pacific time zone.) ll file.html -rw-rw-r-- 1 craighttp2898 Apr 13 19:03 file.html ll ../../public/filters/filter.pl -rwxrwxr-x 1 craighttp 368 Apr 9 14:39 ../../public/filters/filter.pl* HEAD server/form11/file.html 200 OK Cache-Control: max-age=0, public, must-revalidate Connection: close Date: Wed, 14 Apr 2004 02:07:53 GMT Accept-Ranges: bytes ETag: 13ec08a-b52-6312b4c0 Server: Apache/2.0.39 (Unix) Content-Length: 3178 Content-Type: text/html; charset=ISO-8859-1 Expires: Wed, 14 Apr 2004 02:07:53 GMT Last-Modified: Wed, 14 Apr 2004 02:03:39 GMT Client-Date: Wed, 14 Apr 2004 02:04:22 GMT Client-Response-Num: 1 touch ../../public/filters/filter.pl ll file.html -rw-rw-r-- 1 craighttp2898 Apr 13 19:03 file.html ll ../../public/filters/filter.pl -rwxrwxr-x 1 craighttp 368 Apr 13 19:08 ../../public/filters/filter.pl* HEAD server/form11/file.html 200 OK Cache-Control: max-age=0, public, must-revalidate Connection: close Date: Wed, 14 Apr 2004 02:08:28 GMT Accept-Ranges: bytes ETag: 13ec08a-b52-6312b4c0 Server: Apache/2.0.39 (Unix) Content-Length: 3178 Content-Type: text/html; charset=ISO-8859-1 Expires: Wed, 14 Apr 2004 02:08:28 GMT Last-Modified: Wed, 14 Apr 2004 02:03:39 GMT Client-Date: Wed, 14 Apr 2004 02:05:00 GMT Client-Response-Num: 1 touch file.html ll file.html -rw-rw-r-- 1 craighttp2898 Apr 13 19:15 file.html ll ../../public/filters/filter.pl -rwxrwxr-x 1 craighttp 368 Apr 13 19:08 ../../public/filters/filter.pl* HEAD craig-www/form11/file.html 200 OK Cache-Control: max-age=0, public, must-revalidate Connection: close Date: Wed, 14 Apr 2004 02:15:11 GMT Accept-Ranges: bytes ETag: 13ec08a-b52-8c057e80 Server: Apache/2.0.39 (Unix) Content-Length: 3178 Content-Type: text/html; charset=ISO-8859-1 Expires: Wed, 14 Apr 2004 02:15:11 GMT Last-Modified: Wed, 14 Apr 2004 02:15:06 GMT Client-Date: Wed, 14 Apr 2004 02:11:43 GMT Client-Response-Num: 1
