You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by David Dyer-Bennet <dd...@dd-b.net> on 2004/01/21 07:11:01 UTC
Actions of $r->update_mtime
When I call update_mtime I seem to get set_etags done automatically as
well (or perhaps it's set_last_modified that does it?). This is
*BAD*. It's also not documented anywhere I can find online or in
_Writing Apache Modules with Perl and C_. (Apache 1.3.22, mod_perl
1.26).
This comes up in the process of trying to create a module to cause
documents using server-side includes to be served with a last-modified
header but no etag header. I'm at the playing stage, and have a tiny
module, configured as a content handler for my particular test file,
which does update_mtime, set_last_modified, and then returns DECLINED
(causing the request to be processed by default handlers). This works
in the sense that my handler is being invoked (I get errors if there
are errors in it :-)) and the file is served; it appears to be doing
roughly what I expect, except...
I'm getting *both* the mtime I set (either the file mtime if I give no
arg, or the time I give if I give one) in last-modified *and* the
default ETAGS header also, which is bad.
And no documented syntax of set_etag *removes* an etag header, and
undef and 0 haven't given the desired results.
So, any suggestions?
--
David Dyer-Bennet, <ma...@dd-b.net>, <http://www.dd-b.net/dd-b/>
RKBA: <http://noguns-nomoney.com> <http://www.dd-b.net/carry/>
Photos: <dd-b.lighthunters.net> Snapshots: <www.dd-b.net/dd-b/SnapshotAlbum/>
Dragaera/Steven Brust: <http://dragaera.info/>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Actions of $r->update_mtime
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> Oh, I see what you're saying. What's happening is that if I decline,
> it's getting *default*, rather than "what was previously configured".
> Is that what you're saying?
yup.
> Any way to push another content handler
> on the stack, rather than replacing what's there? (Yeah, I can
> replace what's there with a list, I know how to do that.)
you can stack PerlHandlers, but once you DECLINE past all the ones mod_perl
knows about, no, there is no way to escape default-handler at that point.
> > > and I can't find any documentation anywhere
> > > referring to it; google
> >
> > use the source, luke.
>
> After buying a whole book on the topic, in addition to what's online?
> Sheesh. I guess if it's the only way, I'll have to.
well, we authors try our best to document as much as we can. personally, I
had never tried to suppress an ETag header until after ours came out...
good thing there are mailing lists where the people who wrote the code and
books like to answer questions :)
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Actions of $r->update_mtime
Posted by David Dyer-Bennet <dd...@dd-b.net>.
Geoffrey Young <ge...@modperlcookbook.org> writes on 22 January 2004 at 14:02:45 -0500
>
> >>the etag and last-modified headers setting has nothing to do with mod_perl
> >>in this case - it's done by default_handler, so if you fallback to
> >>default_handler then you get to deal with its logic and results.
> >
> >
> > That can't be what's happening; *without* my module, the request is
> > served with *no* last-modified header and *no* etag header -- because
> > it's a document parsed for SSI, and the default handler therefore
> > doesn't provide those things.
>
> well, that's two different things. if you accept the content phase and
> return DECLINED, you get the default-handler. if you don't accept the
> request, then you're getting server-parsed (or whatever else you set it to).
>
> so your module is making a difference, but it's not mod_perl's fault - you'd
> get the same result if you DECLINED from a C content handler.
Oh, I see what you're saying. What's happening is that if I decline,
it's getting *default*, rather than "what was previously configured".
Is that what you're saying? Any way to push another content handler
on the stack, rather than replacing what's there? (Yeah, I can
replace what's there with a list, I know how to do that.)
[snip]
> >>try
> >>
> >>$r->notes('no-etag' => 1);
> >
> >
> > This makes no difference,
>
> it should, or else something is greatly amuck with your situation - I've
> used it myself with success.
>
>
> API_EXPORT_NONSTD(int) ap_send_header_field(request_rec *r,
> const char *fieldname,
> const char *fieldval)
> {
> if (strcasecmp(fieldname, "ETag") == 0) {
> if (ap_table_get(r->notes, "no-etag") != NULL) {
> return 1;
> }
> }
> return (0 < ap_rvputs(r, fieldname, ": ", fieldval, CRLF, NULL));
> }
>
> even though this code checks for non-NULL and '1' ought to work fine, try
>
> $r->notes('no-etag' => 'omit');
I seem to remember documentation explicitly limiting "notes" to being
*strings*, so this might be worth trying (although the notes method
really ought to force a string interpretation on the 1, in that
case). I'll give this a try. The code certainly does look like it
checks for that.
> > and I can't find any documentation anywhere
> > referring to it; google
>
> use the source, luke.
After buying a whole book on the topic, in addition to what's online?
Sheesh. I guess if it's the only way, I'll have to.
--
David Dyer-Bennet, <ma...@dd-b.net>, <http://www.dd-b.net/dd-b/>
RKBA: <http://noguns-nomoney.com> <http://www.dd-b.net/carry/>
Photos: <dd-b.lighthunters.net> Snapshots: <www.dd-b.net/dd-b/SnapshotAlbum/>
Dragaera/Steven Brust: <http://dragaera.info/>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Actions of $r->update_mtime
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>the etag and last-modified headers setting has nothing to do with mod_perl
>>in this case - it's done by default_handler, so if you fallback to
>>default_handler then you get to deal with its logic and results.
>
>
> That can't be what's happening; *without* my module, the request is
> served with *no* last-modified header and *no* etag header -- because
> it's a document parsed for SSI, and the default handler therefore
> doesn't provide those things.
well, that's two different things. if you accept the content phase and
return DECLINED, you get the default-handler. if you don't accept the
request, then you're getting server-parsed (or whatever else you set it to).
so your module is making a difference, but it's not mod_perl's fault - you'd
get the same result if you DECLINED from a C content handler.
>
> *With* my module, it's served with the last-modified date specified in
> my handler -- *not* the date on the file, for example; and it changes
> if I change what my module does -- and with an ETAG value that it gets
> from somewhere.
>
>
>>>And no documented syntax of set_etag *removes* an etag header, and
>>>undef and 0 haven't given the desired results.
>>>
>>>So, any suggestions?
>>
>>try
>>
>>$r->notes('no-etag' => 1);
>
>
> This makes no difference,
it should, or else something is greatly amuck with your situation - I've
used it myself with success.
API_EXPORT_NONSTD(int) ap_send_header_field(request_rec *r,
const char *fieldname,
const char *fieldval)
{
if (strcasecmp(fieldname, "ETag") == 0) {
if (ap_table_get(r->notes, "no-etag") != NULL) {
return 1;
}
}
return (0 < ap_rvputs(r, fieldname, ": ", fieldval, CRLF, NULL));
}
even though this code checks for non-NULL and '1' ought to work fine, try
$r->notes('no-etag' => 'omit');
> and I can't find any documentation anywhere
> referring to it; google
use the source, luke.
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Actions of $r->update_mtime
Posted by David Dyer-Bennet <dd...@dd-b.net>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
> David Dyer-Bennet wrote:
>> When I call update_mtime I seem to get set_etags done automatically as
>> well (or perhaps it's set_last_modified that does it?). This is
>> *BAD*. It's also not documented anywhere I can find online or in
>> _Writing Apache Modules with Perl and C_. (Apache 1.3.22, mod_perl
>> 1.26).
>>
>> This comes up in the process of trying to create a module to cause
>> documents using server-side includes to be served with a last-modified
>> header but no etag header. I'm at the playing stage, and have a tiny
>> module, configured as a content handler for my particular test file,
>> which does update_mtime, set_last_modified, and then returns DECLINED
>> (causing the request to be processed by default handlers). This works
>> in the sense that my handler is being invoked (I get errors if there
>> are errors in it :-)) and the file is served; it appears to be doing
>> roughly what I expect, except...
>>
>> I'm getting *both* the mtime I set (either the file mtime if I give no
>> arg, or the time I give if I give one) in last-modified *and* the
>> default ETAGS header also, which is bad.
>
> the etag and last-modified headers setting has nothing to do with mod_perl
> in this case - it's done by default_handler, so if you fallback to
> default_handler then you get to deal with its logic and results.
That can't be what's happening; *without* my module, the request is
served with *no* last-modified header and *no* etag header -- because
it's a document parsed for SSI, and the default handler therefore
doesn't provide those things.
*With* my module, it's served with the last-modified date specified in
my handler -- *not* the date on the file, for example; and it changes
if I change what my module does -- and with an ETAG value that it gets
from somewhere.
>> And no documented syntax of set_etag *removes* an etag header, and
>> undef and 0 haven't given the desired results.
>>
>> So, any suggestions?
>
> try
>
> $r->notes('no-etag' => 1);
This makes no difference, and I can't find any documentation anywhere
referring to it; google
> and see also the 'FileEtag none' directive
>
> http://httpd.apache.org/docs/mod/core.html#fileetag
Thanks very much, will investigate these.
--
David Dyer-Bennet, <ma...@dd-b.net>, <http://www.dd-b.net/dd-b/>
RKBA: <http://noguns-nomoney.com> <http://www.dd-b.net/carry/>
Photos: <dd-b.lighthunters.net> Snapshots: <www.dd-b.net/dd-b/SnapshotAlbum/>
Dragaera/Steven Brust: <http://dragaera.info/>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Actions of $r->update_mtime
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
David Dyer-Bennet wrote:
> When I call update_mtime I seem to get set_etags done automatically as
> well (or perhaps it's set_last_modified that does it?). This is
> *BAD*. It's also not documented anywhere I can find online or in
> _Writing Apache Modules with Perl and C_. (Apache 1.3.22, mod_perl
> 1.26).
>
> This comes up in the process of trying to create a module to cause
> documents using server-side includes to be served with a last-modified
> header but no etag header. I'm at the playing stage, and have a tiny
> module, configured as a content handler for my particular test file,
> which does update_mtime, set_last_modified, and then returns DECLINED
> (causing the request to be processed by default handlers). This works
> in the sense that my handler is being invoked (I get errors if there
> are errors in it :-)) and the file is served; it appears to be doing
> roughly what I expect, except...
>
> I'm getting *both* the mtime I set (either the file mtime if I give no
> arg, or the time I give if I give one) in last-modified *and* the
> default ETAGS header also, which is bad.
the etag and last-modified headers setting has nothing to do with mod_perl
in this case - it's done by default_handler, so if you fallback to
default_handler then you get to deal with its logic and results.
>
> And no documented syntax of set_etag *removes* an etag header, and
> undef and 0 haven't given the desired results.
>
> So, any suggestions?
try
$r->notes('no-etag' => 1);
and see also the 'FileEtag none' directive
http://httpd.apache.org/docs/mod/core.html#fileetag
HTH
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Actions of $r->update_mtime
Posted by David Dyer-Bennet <dd...@dd-b.net>.
Ged Haywood <ge...@www2.jubileegroup.co.uk> writes:
> Hello there,
>
> On Wed, 21 Jan 2004, David Dyer-Bennet wrote:
>
>> (Apache 1.3.22, mod_perl 1.26).
>> [snip]
>> So, any suggestions?
>
> In addition to Geoff's comments I think you should upgrade ASAP to the
> latest versions of Apache and mod_perl. If you don't, you are likely
> to come up against a few things that have already been fixed. Might
> be a good time also to look at Perl 5.8.3 if you haven't already.
Even RedHat 9 seems to be at 5.8.0; and I hear that's not a good place
to be. And upgrading either apache or perl is a nightmare which I try
to do as seldom as possible.
--
David Dyer-Bennet, <ma...@dd-b.net>, <http://www.dd-b.net/dd-b/>
RKBA: <http://noguns-nomoney.com> <http://www.dd-b.net/carry/>
Photos: <dd-b.lighthunters.net> Snapshots: <www.dd-b.net/dd-b/SnapshotAlbum/>
Dragaera/Steven Brust: <http://dragaera.info/>
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Actions of $r->update_mtime
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hello there,
On Wed, 21 Jan 2004, David Dyer-Bennet wrote:
> (Apache 1.3.22, mod_perl 1.26).
> [snip]
> So, any suggestions?
In addition to Geoff's comments I think you should upgrade ASAP to the
latest versions of Apache and mod_perl. If you don't, you are likely
to come up against a few things that have already been fixed. Might
be a good time also to look at Perl 5.8.3 if you haven't already.
73,
Ged.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html