Re: Is it a subrequest, a redirect or a fast redirect?

Justin Erenkrantz wrote: --On Friday, May 30, 2003 8:23 PM -0400 Bill Stoddard [EMAIL PROTECTED] wrote: I am able to fix the mod_expires problem by doing a test to definitively identify is a request is a subrequest or not (testing r-main is not sufficient). It would be easy to add code to

Re: FW: Apache socket question

Jeff Trawick wrote: While this is probably a bad idea, I bet that if you could trick ap_lingering_close() not to close your socket when the connection is closed, you might be able to get away with this. The relevent line in server/connection.c:214 is: apr_socket_t *csd =

[PATCH] Reworked mod_expires

No failures observed so far with this patch, but more testing is needed. The best part of all is all the code I was able to remove from mod_expires. It would be very cool if someone with the perl-framework setup could test this against the mod_expires test cases and report back the results

Re: [PATCH] Reworked mod_expires

--On Saturday, May 31, 2003 3:00 PM -0400 Bill Stoddard [EMAIL PROTECTED] wrote: No failures observed so far with this patch, but more testing is needed. The best part of all is all the code I was able to remove from mod_expires. It would be very cool if someone with the perl-framework setup

Re: cvs commit: httpd-2.0/modules/ssl mod_ssl.c

Thanks, Justin! Cheers, Erik [EMAIL PROTECTED] wrote: jerenkrantz2003/05/31 12:29:47 Modified:modules/ssl mod_ssl.c Log: Revert revision 1.81 which called non-existent SSL_load_library. No idea where this was seen, but OpenSSL 0.9.7b does not have this. This gets mod_ssl

Re: [PATCH] PR 18388 Set-Cookie header not honored on 304 (Not modified)status

I found some time to look for existing discussions on this... (should have done that earlier)... It isn't valid to send Set-Cookie on a 304. links... the recent 2.0 PR: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18388 (I just closed as invalid.) 1.3 PR that Marc Slemko closed stating

Re: [PATCH] PR 18388 Set-Cookie header not honored on 304(Not modified) status

I found some time to look for existing discussions on this... (should have done that earlier)... It isn't valid to send Set-Cookie on a 304. It is not valid to set a cookie in a 304 response. Please see section 10.3.5 of RFC2616. That is the reason Apache explictly lists headers that will be

Re: [PATCH] PR 18388 Set-Cookie header not honored on 304 (Not modified)status

Greg Marr wrote: I found some time to look for existing discussions on this... (should have done that earlier)... It isn't valid to send Set-Cookie on a 304. It is not valid to set a cookie in a 304 response. Please see section 10.3.5 of RFC2616. That is the reason Apache explictly lists

Re: cvs commit: httpd-2.0/docs/manual/vhosts details.html.en details.html.ko.euc-krexamples.html.en examples.html.ko.euc-kr fd-limits.html.en fd-limi

Justin Erenkrantz wrote: Even if we don't drop the generated files in the repository (which I won't really comment on, other than that Java on FreeBSD isn't very stable - which matters because daedalus is on FreeBSD - someone may want to try to generate the docs on daedalus itself), I think the

Re: mod_dav overhaul

On Thu, May 29, 2003 at 08:38:31AM -0500, Ben Collins-Sussman wrote: ... By the way, for those interested in reading about our best pool practices philosophy, take a look at Subversion's HACKING guidelines -- at the section called APR pool usage conventions. These are the magic formulas that