Re: Apache-Test subdirectory has moved
Geoffrey Young wrote: the Apache-Test/ subdirectory of the perl-framework has migrated to a new location: https://svn.apache.org/repos/asf/perl/Apache-Test what this means for you is that you need to manually adjust your checkout $ rm -rf Apache-Test/ $ svn update ugh, rm is not a good idea if you have modified files in it. should svn switch somehow do the trick instead? -- __ 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: Apache-Test subdirectory has moved
Stas Bekman wrote: Geoffrey Young wrote: the Apache-Test/ subdirectory of the perl-framework has migrated to a new location: https://svn.apache.org/repos/asf/perl/Apache-Test what this means for you is that you need to manually adjust your checkout $ rm -rf Apache-Test/ $ svn update ugh, rm is not a good idea if you have modified files in it. should svn switch somehow do the trick instead? it probably should but it doesn't. just copy your modified files to someplace safe, do the update, then move then back. --Geoff
RE: loading mod_perl first?
Hi,
in TestConfigPerl we have this logic and comment
# modules like Embperl.so need mod_perl.so to be loaded first,
# so make sure that it's loaded before files inherited from the
# global httpd.conf
$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
what this does is load mod_perl.so ahead of all other
modules, giving it least priority. there are a few problems
I see with this
- in 1.3 this is a _very_ untypical setup - mod_perl.so
needs to be loaded last so that it gets first crack at each phase.
- in 2.X order doesn't matter due to the new hooking API,
but it _does_ matter for overriding directives. that is, you
can't load mod_perl.so first and get first crack at
_directive_ parsing.
anyway, I guess what I'm saying is that 99% of the time we
want mod_perl to have the highest priority, but we do the
exact opposite with Apache-Test, which is probably ungood.
now, in all fairness to embperl I don't want to just yank
this out without giving gerald some alternative. however, I
think it's a bad idea to create a test environment that
doesn't accurately represent the most common case.
so, here are some possible solutions...
- historically I think this was introduced before we had
extra.last.conf.in functionality. gerald, does using that
file help you?
I don't use Apache::Test (unless I install a new mod_perl and run make
test). If I remember right the reason why this was introduced, was that
mod_perl copied the LoadModule over from httpd.conf and the tests fails
then, when Embperl.so is loaded before mod_perl.so, because there are
unresolved symbols.
I am not sure if this is still a problem.
- we could provide for an extra argument to
configure_libmodperl() which would place mod_perl.so first
instead of the (new) default of last. this would allow folks
like embperl to do something like
package My::TestConfigurePerl;
our @ISA = qw(Apache::TestConfigurePerl);
sub configure_libmodperl { shift-SUPER::configure_libmodperl(1) }
and have things work the way they did before. patch attached.
I am not sure if I understand the whole picture, since digging in
Apache::Test was some time ago for me, but it looks like that this change
might make sense.
Gerald
thoughts?
--Geoff
Re: Apache-Test subdirectory has moved
Also Geoff please don't forget to update the documentation. Both inside the module and at perl.apache.org docs. Thanks. I couldn't find any mentions of the location of the repository outside of README-SVN. do you know of others? additionally, we should probably update httpd.apache.org/test and create a home for Apache-Test under perl.apache.org. --Geoff
preload modules at sever startup
Hi,
I'm looking for some suggestions for a library problem with Apache::Test,
which I'm using to develop a web application.
Hope this is the place to ask.
Using Apache 1 and Mod perl 1, how can I preload perl modules at server
startup?
My extra.conf.in contains something like this:
PerlModule Foo::Bar
Location /a
SetHandler perl-script
PerlHandler Foo::Bar::myhandler
/Location
make test fails. The apache server won't start because it can't find
Foo::Bar, needed by the line PerlModule Foo::Bar
In the link below, I read about PerlSwitches [EMAIL PROTECTED]@/../lib
http://perl.apache.org/docs/general/testing/testing.html#Extending_Configuration_Setup
Is PerlSwitches for MP2 only?
In the link above I'd call the root development directory
/path/to/Apache-Amazing, just so that you understand what I mean by root
development directory. Here is a listing of the root development
directory:
CVS/ Changes MANIFEST MANIFEST.OLD MANIFEST_maybe META.yml Makefile
Makefile.PL README blib/ docs/ lib/ pm_to_blib t/
Of course Foo::Bar is in lib/Foo/Bar.pm (until Apache::Test moves it to
blib/ )
If I set PERL5LIB to the root development directory, the make test runs
fine (well it shows me my programming errors is what I mean).
Should I create a starup.pl file that does something like:
BEGIN { use lib @[EMAIL PROTECTED]/lib }
Then and add lines to extra.conf.in to run startup.pl.
Or is there a better way? A hard coded path won't work in my situation
(which is why I use the @ServerRoot@).
Thanks in advance,
Jim
Re: preload modules at sever startup
Jim Martinez wrote:
Hi,
I'm looking for some suggestions for a library problem with Apache::Test,
which I'm using to develop a web application.
Hope this is the place to ask.
better [EMAIL PROTECTED] now, but that list was just created yesterday :)
Using Apache 1 and Mod perl 1, how can I preload perl modules at server
startup?
My extra.conf.in contains something like this:
PerlModule Foo::Bar
Location /a
SetHandler perl-script
PerlHandler Foo::Bar::myhandler
/Location
make test fails. The apache server won't start because it can't find
Foo::Bar, needed by the line PerlModule Foo::Bar
if you can move it to t/lib/Foo/Bar.pm Apache-Test will pick it up.
In the link below, I read about PerlSwitches [EMAIL PROTECTED]@/../lib
http://perl.apache.org/docs/general/testing/testing.html#Extending_Configuration_Setup
Is PerlSwitches for MP2 only?
yes. an equivalent in mp1 might be to do this in extra.conf.in
Perl
use lib qw(@ServerRoot@/../lib)
/Perl
or without the Perl sections from modperl_extra.pl.in, which is equivalent
to startup.pl but with @var@ substitution. you can use modperl_extra.pl if
you don't need substitution.
keep in mind that if you go this route you will probably need to change
extra.conf.in to extra.last.conf.in so that it is loaded _after_ your
startup.pl. see the bottom of the generated httpd.conf to see what I mean.
In the link above I'd call the root development directory
/path/to/Apache-Amazing, just so that you understand what I mean by root
development directory. Here is a listing of the root development
directory:
CVS/ Changes MANIFEST MANIFEST.OLD MANIFEST_maybe META.yml Makefile
Makefile.PL README blib/ docs/ lib/ pm_to_blib t/
Of course Foo::Bar is in lib/Foo/Bar.pm (until Apache::Test moves it to
blib/ )
If I set PERL5LIB to the root development directory, the make test runs
fine (well it shows me my programming errors is what I mean).
Should I create a starup.pl file that does something like:
BEGIN { use lib @[EMAIL PROTECTED]/lib }
Then and add lines to extra.conf.in to run startup.pl.
Or is there a better way? A hard coded path won't work in my situation
(which is why I use the @ServerRoot@).
no, that's the idea. you just need to use the magic files :)
HTH
--Geoff
Re: loading mod_perl first?
may be we should be more flexible right away and use the same approach Apache uses, i.e. have each custom module a say for its insertion priority. So we could add mod_perl as middle module and give other modules an opportunity to load themselves before (first/very_first or after (last/very_last) mod_perl or some other module. It really shouldn't be mod_perl centric as more and more non-perl projects start to use A-T. well, I think this is kinda a mod_perl problem, since we're only talking about TestConfigurePerl and it's special treatment of mod_perl. if you use TestConfig or TestConfigPHP then the modules are just inherited from httpd.conf (mod_perl included) in the order in which they appear there, which is typically what the user wants. in general, I think it is atypical that one apache module depends on another module being loaded before it itself can load. that is, in a LoadModule sense - sure, lots of things depend on mod_perl, but they use PerlModule not LoadModule. embperl seems to be the exception to this. axkit would be the only other I could think of but I just verified that it uses PerlModule as well. So instead of printing the modules right away they could be assembled into an array which will be then resorted the way the user wants. e.g.: add_foo(, before = mod_perl.c); add_foo(, after = qw[mod_perl.c mod_proxy.c]); or have those before/after/last/first/etc encoded in the API instead... well, I think that for the most part inheriting order from httpd.conf is sufficient, at least for the moment, but we can always create a larger API later when time allows. for the moment, though, I think I'm happy to make an exception for embperl within TestConfigPerl. at least until somebody complains :) --Geoff
Re: loading mod_perl first?
Geoffrey Young wrote: in general, I think it is atypical that one apache module depends on another module being loaded before it itself can load. that is, in a LoadModule sense - sure, lots of things depend on mod_perl, but they use PerlModule not LoadModule. embperl seems to be the exception to this. axkit would be the only other I could think of but I just verified that it uses PerlModule as well. Don't the new 2.x proxy modules have the same type of dependency? mod_proxy_connect, mod_proxy_http and mod_proxy_ftp require mod_proxy, but I've never tried loading them out of order to see if they fail. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: loading mod_perl first?
Christopher H. Laco wrote:
Geoffrey Young wrote:
in general, I think it is atypical that one apache module depends on
another
module being loaded before it itself can load. that is, in a LoadModule
sense - sure, lots of things depend on mod_perl, but they use
PerlModule not
LoadModule. embperl seems to be the exception to this. axkit would
be the
only other I could think of but I just verified that it uses
PerlModule as well.
Don't the new 2.x proxy modules have the same type of dependency?
mod_proxy_connect, mod_proxy_http and mod_proxy_ftp require mod_proxy,
but I've never tried loading them out of order to see if they fail.
yeah, that seems to be the case. and apparently there are some things that
may require mod_dav as well.
but generally this isn't an issue, since we inherit the order, as well as
module location, from httpd.conf. of course, if mod_dav wanted to use
Apache-Test for its own development it wouldn't inherit from httpd.conf but
would create its own TestConfigDav.pm class to handle things for it.
what makes mod_perl unique in this circumstance is that we are making
exception for Embperl, which is really a third party module that we have no
control over - anybody can have a custom mod_foo that depends on mod_perl or
any other module, but that doesn't mean we need to account for it in
Apache-Test land.
anyway, I'm starting to think that the best solution is like the one I've
attached here, at least for the moment. what this means is that people with
Embperl in their httpd.conf won't have problems, while people wanting to
explicitly test Embperl will have to do what everyone else needs to do -
subclass TestConfig.pm and determine the module loading order themselves.
--Geoff
Index: TestRunPerl.pm
===
--- TestRunPerl.pm (revision 153110)
+++ TestRunPerl.pm (working copy)
@@ -35,6 +35,9 @@
# Apache::TestConfigPerl already configures mod_perl.so
Apache::TestConfig::autoconfig_skip_module_add('mod_perl.c');
+
+# skip over Embperl.so - it's funky
+Apache::TestConfig::autoconfig_skip_module_add('Embperl.c');
}
sub configure_modperl {
Index: TestConfigPerl.pm
===
--- TestConfigPerl.pm (revision 153110)
+++ TestConfigPerl.pm (working copy)
@@ -94,10 +94,7 @@
debug $msg;
}
-# modules like Embperl.so need mod_perl.so to be loaded first,
-# so make sure that it's loaded before files inherited from the
-# global httpd.conf
-$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
+$self-preamble(IfModule = '!mod_perl.c', $cfg);
}
Re: Apache-Test subdirectory has moved
Geoffrey Young wrote: Also Geoff please don't forget to update the documentation. Both inside the module and at perl.apache.org docs. Thanks. I couldn't find any mentions of the location of the repository outside of README-SVN. do you know of others? if you don't find any with grep, then there are none. So we should add one then :) additionally, we should probably update httpd.apache.org/test and create a home for Apache-Test under perl.apache.org. I see that you added test/ but it's probably not the most intuitive naming. I think perl.apache.org/Apache-Test/ is more sensible. And maybe moving testing.pod there would be great too. s/testing.pod/tutorial.pod/? And of course links to it need to be adjusted too, to reflect the new location. (and Apache/README and other docs, like .pm files) -- __ 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: loading mod_perl first?
Geoffrey Young wrote:
+1
Index: TestRunPerl.pm
===
--- TestRunPerl.pm (revision 153110)
+++ TestRunPerl.pm (working copy)
@@ -35,6 +35,9 @@
# Apache::TestConfigPerl already configures mod_perl.so
Apache::TestConfig::autoconfig_skip_module_add('mod_perl.c');
+
+# skip over Embperl.so - it's funky
+Apache::TestConfig::autoconfig_skip_module_add('Embperl.c');
}
sub configure_modperl {
Index: TestConfigPerl.pm
===
--- TestConfigPerl.pm (revision 153110)
+++ TestConfigPerl.pm (working copy)
@@ -94,10 +94,7 @@
debug $msg;
}
-# modules like Embperl.so need mod_perl.so to be loaded first,
-# so make sure that it's loaded before files inherited from the
-# global httpd.conf
-$self-preamble_first(IfModule = '!mod_perl.c', $cfg);
+$self-preamble(IfModule = '!mod_perl.c', $cfg);
}
--
__
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: Apache-Test subdirectory has moved
Stas Bekman wrote: Geoffrey Young wrote: Also Geoff please don't forget to update the documentation. Both inside the module and at perl.apache.org docs. Thanks. I couldn't find any mentions of the location of the repository outside of README-SVN. do you know of others? if you don't find any with grep, then there are none. So we should add one then :) additionally, we should probably update httpd.apache.org/test and create a home for Apache-Test under perl.apache.org. I see that you added test/ but it's probably not the most intuitive naming. I think perl.apache.org/Apache-Test/ is more sensible. And maybe moving testing.pod there would be great too. s/testing.pod/tutorial.pod/? And of course links to it need to be adjusted too, to reflect the new location. (and Apache/README and other docs, like .pm files) and probably a rewrite rule should be added too for those who link directly to that URL. http://perl.apache.org/docs/general/testing/testing.html#Extending_Configuration_Setup of course we could avoid all that, by keeping the tutorial where it is, and just add a link from config.cfg to it. -- __ 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: Apache-Test subdirectory has moved
if you don't find any with grep, then there are none. So we should add one then :) :) yes, now that it's officially ours we should do more to publicise it. additionally, we should probably update httpd.apache.org/test and create a home for Apache-Test under perl.apache.org. I see that you added test/ but it's probably not the most intuitive naming. I think perl.apache.org/Apache-Test/ is more sensible. that's cool. additionally I think we should have subdirectories for each of the supported languages /Apache-Test/perl /Apache-Test/php /Apache-Test/parrot (someday soon) and so on. in fact, it was the need for a home for php-related docs and whatnot that prompted this move in the first place ;) And maybe moving testing.pod there would be great too. s/testing.pod/tutorial.pod/? yes, specifically under /Apache-Test/perl was what I was going to suggest. And of course links to it need to be adjusted too, to reflect the new location. (and Apache/README and other docs, like .pm files) yes. and probably a rewrite rule should be added too for those who link directly to that URL. http://perl.apache.org/docs/general/testing/testing.html#Extending_Configuration_Setup good idea. from an .htaccess file or do we do that in the core httpd.conf? of course we could avoid all that, by keeping the tutorial where it is, and just add a link from config.cfg to it. sure. but what I'm hoping to accomplish is a more coherent set of documentation for Apache-Test that transcends what we've done (and documented well) over in mod_perl-land. so shuffling things about would help that I think. you? --Geoff
Entity headers in 304 reponse, WAS: RE: svn commit: r152973 - in httpd/httpd/trunk/modules/cache: cache_storage.c mod_cache.c mod_cache.h mod_disk_cache.c
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 2:39 AM New Revision: 152973 [...] +/* RFC 2616 10.3.5 states that entity headers are not supposed + * to be in the 304 response. Therefore, we need to load in the + * cached headers before we update the cached headers. That's not how I read that section. 14.26 has some specific text stating cache-related header fields should be included. Sander
install warnings
Hi, I'm new to apache. I've built httpd-2.1 out of the latest cvs. I got the following warning messages during installation: Installing build system files libtool: install: warning: `/usr/local/src/apache/httpd-2.1/srclib/aprutil/libaprutil-1.la' has not been installed in `/usr/local/apache2/lib' libtool: install: warning: `/usr/local/src/apache/httpd-2.1/srclib/apr/libapr-1.la' has not been installed in `/usr/local/apache2/lib' Looking into /usr/local/apache2/lib there were only libaprutil1-1.a and libapr-1.a. So I went ahead and manually copied those 2 files over and perform another make install. Not sure what happened there ? -- Qing
Re: mod_cache and Etag headers
Hi, Justin Erenkrantz [EMAIL PROTECTED] writes: Okay, please try again. =) I've committed fixes in r152973: these should go some way to addressing these problems. works fine now! Thank you, David
[PATCH] remove formatting from ap_log_error calls
ap_log_error escapes escape sequences such as newline and tab so that
they appear as the two-character strings \t or \n in error_log
(unless httpd was
built with -DAP_UNSAFE_ERROR_LOG_UNESCAPED) as fallout from CAN-2003-0020
Some callers throughout the code still send '\n' within the string argument sent
to ap_log_error, trivial patch attached removes the formatting from these calls.
--
Eric Covener
[EMAIL PROTECTED]
Index: server/mpm/winnt/mpm_winnt.c
===
--- server/mpm/winnt/mpm_winnt.c (revision 152675)
+++ server/mpm/winnt/mpm_winnt.c (working copy)
@@ -669,7 +669,7 @@
if ((rv = apr_procattr_io_set(attr, APR_FULL_BLOCK,
APR_NO_PIPE, APR_NO_PIPE)) != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, ap_server_conf,
-Parent: Unable to create child stdin pipe.\n);
+Parent: Unable to create child stdin pipe.);
apr_pool_destroy(ptemp);
return -1;
}
@@ -680,7 +680,7 @@
|| ((rv = apr_procattr_child_out_set(attr, child_out, NULL))
!= APR_SUCCESS)) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, ap_server_conf,
-Parent: Unable to connect child stdout to NUL.\n);
+Parent: Unable to connect child stdout to NUL.);
apr_pool_destroy(ptemp);
return -1;
}
@@ -698,7 +698,7 @@
if ((rv = apr_procattr_child_err_set(attr, child_err, NULL))
!= APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, ap_server_conf,
-Parent: Unable to connect child stderr.\n);
+Parent: Unable to connect child stderr.);
apr_pool_destroy(ptemp);
return -1;
}
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c (revision 152675)
+++ modules/proxy/proxy_util.c (working copy)
@@ -619,7 +619,7 @@
if (bits != 32) /* no warning for fully qualified IP address */
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
- Warning: NetMask not supplied with IP-Addr; guessing: %s/%ld\n,
+ Warning: NetMask not supplied with IP-Addr; guessing: %s/%ld,
inet_ntoa(This-addr), bits);
}
@@ -627,11 +627,11 @@
if (*addr == '\0' (This-addr.s_addr ~This-mask.s_addr) != 0) {
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
-Warning: NetMask and IP-Addr disagree in %s/%ld\n,
+Warning: NetMask and IP-Addr disagree in %s/%ld,
inet_ntoa(This-addr), bits);
This-addr.s_addr = This-mask.s_addr;
ap_log_error(APLOG_MARK, APLOG_STARTUP, 0, NULL,
- Set to %s/%ld\n,
+ Set to %s/%ld,
inet_ntoa(This-addr), bits);
}
Index: modules/proxy/ajp_link.c
===
--- modules/proxy/ajp_link.c (revision 152675)
+++ modules/proxy/ajp_link.c (working copy)
@@ -118,7 +118,7 @@
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, NULL,
ajp_ilink_receive() received packet len=% APR_SIZE_T_FMT
- type=%d\n,
+ type=%d,
blen, (int)msg-buf[hlen]);
return APR_SUCCESS;
Index: modules/ssl/ssl_engine_kernel.c
===
--- modules/ssl/ssl_engine_kernel.c (revision 152675)
+++ modules/ssl/ssl_engine_kernel.c (working copy)
@@ -563,7 +563,7 @@
if (renegotiate !renegotiate_quick (r-method_number == M_POST)) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, r-server,
SSL Re-negotiation in conjunction
- with POST method not supported!\n
+ with POST method not supported!
hint: try SSLOptions +OptRenegotiate);
return HTTP_METHOD_NOT_ALLOWED;
@@ -1818,7 +1818,7 @@
else if (where SSL_CB_ALERT) {
char *str = (where SSL_CB_READ) ? read : write;
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
- %s: Alert: %s:%s:%s\n,
+ %s: Alert: %s:%s:%s,
SSL_LIBRARY_NAME, str,
SSL_alert_type_string_long(rc),
SSL_alert_desc_string_long(rc));
Re: [PATCH] remove formatting from ap_log_error calls
On Wed, 9 Feb 2005 09:36:09 -0500, Eric Covener [EMAIL PROTECTED] wrote: ap_log_error escapes escape sequences such as newline and tab so that they appear as the two-character strings \t or \n in error_log (unless httpd was built with -DAP_UNSAFE_ERROR_LOG_UNESCAPED) as fallout from CAN-2003-0020 Some callers throughout the code still send '\n' within the string argument sent to ap_log_error, trivial patch attached removes the formatting from these calls. looks simple/correct to me; I'll commit later today unless somebody has a flash of insight about why this is bad
Re: Entity headers in 304 reponse, WAS: RE: svn commit: r152973 - in httpd/httpd/trunk/modules/cache: cache_storage.c mod_cache.c mod_cache.h mod_disk_cache.c
--On Wednesday, February 9, 2005 10:47 AM +0100 Sander Striker [EMAIL PROTECTED] wrote: [...] +/* RFC 2616 10.3.5 states that entity headers are not supposed + * to be in the 304 response. Therefore, we need to load in the + * cached headers before we update the cached headers. That's not how I read that section. 14.26 has some specific text stating cache-related header fields should be included. Section 10.3.5 says: If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. The headers specifically listed are: Date, ETag and/or Content-Location, Expires, Cache-Control, and/or Vary. Hence, the response headers from the origin server on a 304 response aren't guaranteed to be complete. So, what this commit does now is load in the stored cached response headers and interleaving them with the headers we just received as part of the 304 response - retaining the just-received headers if there is overlap. Then, we're updating our cache entry with this new merged set of headers. The issue here is that you can't just take the response headers from a 304 header and use them and them alone to update the cache: you need to 'merge' in what you already have to be complete. As an aside, see line 934 in modules/http/http_filters.c for what httpd sends on a 304: all other header fields are stripped. Or, do you see a better way? Or, is there a way to make the comment clearer? -- justin
RE: Entity headers in 304 reponse, WAS: RE: svn commit: r152973 - in httpd/httpd/trunk/modules/cache: cache_storage.c mod_cache.c mod_cache.h mod_disk_cache.c
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 6:20 PM [...] Hence, the response headers from the origin server on a 304 response aren't guaranteed to be complete. So, what this commit does now is load in the stored cached response headers and interleaving them with the headers we just received as part of the 304 response - retaining the just-received headers if there is overlap. Then, we're updating our cache entry with this new merged set of headers. Yeah, I misread the comment. The issue here is that you can't just take the response headers from a 304 header and use them and them alone to update the cache: you need to 'merge' in what you already have to be complete. Sure. As an aside, see line 934 in modules/http/http_filters.c for what httpd sends on a 304: all other header fields are stripped. Ah yes, makes sense. Nice to have a guard on the way out. Or, do you see a better way? Or, is there a way to make the comment clearer? I think I've clarified the comment slightly in rev 153104. But honestly, it was just me. Sander
Decreasing need to recompile buildmark.c?
I'd like to see what we can do to minimize our need to always recompile buildmark.c. Ideally, it should only need to be recompiled if httpd is being relinked for some other reason - not every single time make is run. One possibility might be to do something via the $(PROGRAM_NAME) target in build/program.mk - i.e. compile buildmark right before we do the httpd link. Thoughts? Any other brilliant strategies come to mind? -- justin
2.0.53 on Windows
Forgive me if this has already been mentioned, but I can't find anything in the archives. Is anybody planning on packaging a Windows version of the source files? Thanks, Alex.
Re: Decreasing need to recompile buildmark.c?
I did exactly that for win32. The old win32 build system recompiled buildmark.c as a build step (bleh.) The new win32 build system has the compilation of buildmark.c as a prelink step - if we aren't linking libhttpd, we don't recompile buildmark. Seemed to be a trivial solution, and avoided many, many worthless relink's, since recompiling buildmark.c forces the linker. Bill At 02:11 PM 2/9/2005, Justin Erenkrantz wrote: I'd like to see what we can do to minimize our need to always recompile buildmark.c. Ideally, it should only need to be recompiled if httpd is being relinked for some other reason - not every single time make is run. One possibility might be to do something via the $(PROGRAM_NAME) target in build/program.mk - i.e. compile buildmark right before we do the httpd link. Thoughts? Any other brilliant strategies come to mind? -- justin
Re: 2.0.53 on Windows
Yes to both (source files, and binaries). Forgive, it's been a busy week and as .53 isn't a security release, this hasn't been at the top of my agenda :) Promise, the next security release, binaries + source .zip balls will be in-sync with the announce. Bill At 02:55 PM 2/9/2005, Alex Varju wrote: Forgive me if this has already been mentioned, but I can't find anything in the archives. Is anybody planning on packaging a Windows version of the source files? Thanks, Alex.
Re: The use of CORE_PRIVATE
Quoting Bojan Smojver [EMAIL PROTECTED]: I'm trying to rely on functions that help in creating sub-requests, Actually, that would be requests as well, not just sub-requests. -- Bojan
