Getting User and Group from custom httpd.conf
Hi, This is my first posting to the list so please forgive my ignorance of any customs. I am in the process of getting a test environment setup using the Apache::Test package. While originally installing the package a few months ago, I ran into a couple of problems which I posted to rt.cpan.org. Stas kindly replied to both my tickets: #3860- a comment about problems with custom httpd in /usr/local/apache/bin #3861- problems with the generation of the httpd.conf file Over the course of our conversation about the latter bug, Stas explained that User and Group directives get set to 'nobody' if TEST is run as root, otherwise these values get set to the current user. My web environment is setup with 'www' as the owner of the Apache processes so I needed to pass in the -User and -Group parameters to TEST to get the proper settings for my environment. Stas suggested that I look into a way of reading these values from the system-installed httpd.conf file. I began to work on that task last evening (yeah, I got a bit derailed for a few months). While doing so, I sent the message at the end of this email to Stas. He suggested that I join the mailing list and post my findings here. As I contemplate this matter after a night's rest, I'm wondering if it's such a good idea to get the values of User and Group from the httpd.conf. It was rather easy to add the ability to pull these entries from the original http.conf (save some extra logic that needs to be written to only retrieve the first set from the global options) which makes me wonder if there was a reason these have been purposely left out of the TestConfigParse.pm module. Thanks for any advice and pointers. William - Forwarded message from Stas Bekman [EMAIL PROTECTED] - To: [EMAIL PROTECTED] From: Stas Bekman [EMAIL PROTECTED] Date: Thu, 11 Dec 2003 20:52:12 -0800 Subject: [Fwd: [cpan #3861] Custom t/conf/httpd.conf.in is ignored] Organization: Hope, Humanized Hi William, this shouldn't be a private discussion. There is a team of developers that handle that module. So if you'd be so kind to repost this to [EMAIL PROTECTED] and may be giving some more background on what you are trying to overcome, that would be very helpful. (You may want to subscribe to the list first - [EMAIL PROTECTED], otherwise it may take some time for your message to get approved). I'm about to leave shortly and won't be able to look at it untill I'm back a few days later. So may be Geoff will be able to work with you to resolve the issue while I'm away. Thank you. Original Message Subject: [cpan #3861] Custom t/conf/httpd.conf.in is ignored Date: Thu, 11 Dec 2003 21:26:54 -0500 (EST) From: Guest via RT [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: AdminCc of cpan Ticket #3861: ; This message about Apache-Test was sent to you by guest via rt.cpan.org Full context and any attached attachments can be found at: URL: https://rt.cpan.org/Ticket/Display.html?id=3861 [STAS - Fri Oct 3 18:25:27 2003]: You should be able to grep for this kind of tokens. It's coming from TestConfigParse.pm. Hi Stas, I've finally had a chance to take another look at parsing the httpd.conf file for the Group and User settings. I looked in the TestConfigParse.pm file; there's some nice, but complex, code in that module. From what I could figure out, the %wanted_config contains a hash of hashes which is used to parse the config file. The TAKE1 group appears to be made for retrieving a single key, so I added User and Group to that list. Now, however, I'm stuck. If I dump the vars hashref after running inherit_config, the values of User and Group are my user id 'william' (despite the fact that I'm running the script as root). I also looked at the value of User when it was being parsed inside of the inheret_config_file_or_directory sub. The script had the right values. I tried debugging but this part of the code is wrapped inside of an eval which sets ulimit before calling the script again. Is there a way to debug under this situation? So, I'm not sure what needs to happen to get the correct User and Group values into the vars hash. Sorry it's been so long but hopefully you can pick up the thread by reviewing the messages at rt.cpan.org. Now that I think about it, it could be that the parsing routine is getting the last User and Group values. Looking at my httpd.conf, this appears to be the case. However, those are settings for a VirtualHost which probably isn't what we want. We want the global User and Group settings which is typically(?) going to be the first value. So, how to skip further user and group lines in the parsing? Any suggestions? Thanks, William -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---
Re: Redo for Patch for cookie processing in Flood
On Tue, 28 Oct 2003 10:12:19 -0500 (EST)
Norman Tuttle [EMAIL PROTECTED] wrote:
Hello Norman,
As per the suggestions I have received, I am resubmitting the attached
diff for the cookies changes in the proper format.
See the inline comments for what has been fixed by this patch.
Please see attached diff. It's basically your patch with some minor
corrections:
1. Follow style guide more closely
2. Remove some comments
3. Replace respend with headers end. Do a test for page that has 'Set-Cookie:'
string in its body to see why :)
If those small changes are OK with you, I'll commit your patch soon.
Note that this patch alone does not provide the most robust solution as it
ignores the possibility of different cookies with the same name going
to different hosts, but for this and observation of expiration dates, etc,
we would have to expand the Flood model of cookies to store that
information as well, which is currently not being done.
Yup. Besides that we need to check for Set-Cookie2: header, and allow for
custom (specified in configuration) cookies to be sent. Anyway your patch is a
step towards right direction.
I'll try to review a bunch of your other patches. I'm really sorry, that this
takes sooo long, but I'm dead busy with work. Looks like this holds true for
other flood dev'ers (because of that we haven't released flood-1.1 to
public!). Anyway, your patches have a nice, quiet place on my disk until I get
more free time to spent on flood development.
regards,
--
Jacek Prucia
diff -urN flood.orig/flood_round_robin.c flood/flood_round_robin.c
--- flood.orig/flood_round_robin.c 2003-12-12 23:18:45.0 +0100
+++ flood/flood_round_robin.c 2003-12-12 23:26:20.0 +0100
@@ -897,42 +897,65 @@
response_t *resp)
{
round_robin_profile_t *rp;
-char *cookieheader, *cookievalue, *cookieend;
+char *cookieheader, *cookievalue, *cookieend, *headersend;
+unsigned size;
rp = (round_robin_profile_t*)profile;
-/* FIXME: This algorithm sucks. I need to be shot for writing such
- * atrocious code. Grr. */
-cookieheader = strstr(resp-rbuf, Set-Cookie: );
-if (cookieheader)
-{
-/* Point to the value */
+/* handle (possibly) multiple cookies */
+cookieend = resp-rbuf;
+headersend = strstr(resp-rbuf, \r\n\r\n);
+
+while ((cookieheader = strstr(cookieend, Set-Cookie: )) != NULL) {
+
cookieheader += 12;
-cookievalue = (char*) memchr(cookieheader, '=',
- resp-rbufsize - (int)(cookieheader -
(int)(resp-rbuf)));
-if (cookievalue)
-{
-cookie_t * cookie = apr_pcalloc(rp-pool, sizeof(cookie_t));
-
-++cookievalue;
-cookie-name = apr_palloc(rp-pool, cookievalue - cookieheader);
-apr_cpystrn(cookie-name, cookieheader, cookievalue -
cookieheader);
-
-cookieheader = cookievalue;
-cookieend = (char*) memchr(cookieheader, '\r',
- resp-rbufsize - (int)(cookieheader -
(int)(resp-rbuf)));
+cookievalue = (char*) memchr(cookieheader, '=', headersend -
cookieheader);
+
+if (cookievalue) {
+
+cookie_t * cookie = NULL, *cook = rp-cookie;
+size = cookievalue - cookieheader;
+
+while (cook) {
+if ((strlen(cook-name) == size)
+ (!strncasecmp(cookieheader, cook-name, size))) {
+cookie = cook;
+break;
+}
+cook = cook - next;
+}
+
+if (!cookie) {
+cookie = apr_pcalloc(rp-pool, sizeof(cookie_t));
+cookie-name = apr_palloc(rp-pool, ++size);
+apr_cpystrn(cookie-name, cookieheader, size);
+}
+
+cookieheader = cookievalue + 1;
+cookieend = (char*) memchr(cookieheader, '\r', headersend -
cookieheader);
+
+/* This should not be happening. */
+if (!cookieend) {
+break;
+}
+
cookievalue = (char*) memchr(cookieheader, ';',
- cookieend - cookieheader);
-if (!cookievalue)
+ cookieend - cookieheader);
+if (!cookievalue) {
cookievalue = cookieend;
+}
-++cookievalue;
-
-cookie-value = apr_palloc(rp-pool, cookievalue - cookieheader);
-apr_cpystrn(cookie-value, cookieheader,
-cookievalue - cookieheader);
-cookie-next = rp-cookie;
-rp-cookie = cookie;
+size = cookievalue + 1 - cookieheader;
+if ((!cook) || (size strlen(cookie-value) + 1)) {
+cookie-value = apr_palloc(rp-pool, size);
+}
+apr_cpystrn(cookie-value, cookieheader, size);
+
+/* if
Re: filtering huge request bodies (like 650MB files)
Aaron Bannert wrote: On Thu, Dec 11, 2003 at 01:50:46PM -0600, William A. Rowe, Jr. wrote: But the 2.0 architecture is entirely different. We need a poll but it's not entirely obvious where to put one... One suggestion raised in a poll bucket: when a connection level filter cannot read anything more, it passed back a bucket containing a poll descriptor as metadata. Each filter passes this metadata bucket back up. Some filters like mod_ssl would move it from the connection brigade to the data brigade. At one level we'll have to fit whatever I/O multiplexer we come up with in the filters. I'm going to stay out of that discussion. At a lower level, ignoring filters for a moment, we still need a way for applications to be able to multiplex I/O between different I/O types: pipes, files, sockets, IPC, etc... I think this is the root of the problem (and something we should probably move over to the [EMAIL PROTECTED] list, and also something we might want to take up after APR 1.0 is released). This was exactly the conversation we were having at the hackathon. As always, Windows was the problem, but I thought Bill had it licked? 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: filtering huge request bodies (like 650MB files)
On Thu, Dec 11, 2003 at 10:35:28PM -0600, William A. Rowe, Jr. wrote: I've been thinking the same thing driving around this evening... One major goal of httpd-3.0 is *finally* arriving at something that starts looking async. We've kicked it around some time, but perhaps it's time to start looking at the async poll implementation, to get some idea of how we can 'poll' on multiple sorts of events. The one thing that is clear to me, pre-1.0: win32 needs to be able to poll pipes and sockets, *even* if it means a really lame 100ms timeout (perhaps configurable) on the socket poll to look sideways at the pipe info. There is no way to solve any of these problems without clearing that first hurdle. On platforms where pipes are not an advantage over sockets, why not use socketpair() instead of pipe()? Cheers, Glenn
C++ compilation issue with command_rec
Hi, I am developing an Apache module in C++ and have come across this issue that I am unable to resolve even after hours of effort. I will appreciate any idea/suggestion to resolve this. When compiling with g++, the compiler gives the following error at the directives declaration (command_rec) invalid conversion from `const char*(*)(cmd_parms*, void*, const char*) ' to `const char*(*)()' I have tried many workarounds including shifting directive declaration outside class structure, but it appears g++ doesn't like the underlying code. I have also tried following the macros in http_config.h, but have been unable to come up with a workable solution to resolve this problem. Open to any suggestion/idea. Thanks A. Mujeer
2.0, Subrequest and Digest auth
I ran into a snag(1) with Digest-Auth, mod_dav and dav_svn. I understood from Sander that this was a known subrequest issue ? But have not found any discussion Any pointers / message-ID's for me; I just need to get it fixed and am poised to fire up vim^H. Ta, Dw 1: need to run Subversion repo either behind a 1.3 proxy or on a non 80/443 port - plus the passwed cannot be in the clear; but the 1.3. proxy does not progagate PROPFIND correctly, subversion does not want to play nice with httpS on a non 443 port and 2.0 does not want to do digest auth - so fxing the latter seems the quickest route to bliss and meeting the ops requirements. Help appreciated :-)
Re: 2.0, Subrequest and Digest auth
On Fri, 2003-12-12 at 16:11, Dirk-Willem van Gulik wrote: I ran into a snag(1) with Digest-Auth, mod_dav and dav_svn. I understood from Sander that this was a known subrequest issue ? But have not found any discussion Any pointers / message-ID's for me; I just need to get it fixed and am poised to fire up vim^H. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25040 Sander Ta, Dw 1: need to run Subversion repo either behind a 1.3 proxy or on a non 80/443 port - plus the passwed cannot be in the clear; but the 1.3. proxy does not progagate PROPFIND correctly, subversion does not want to play nice with httpS on a non 443 port and 2.0 does not want to do digest auth - so fxing the latter seems the quickest route to bliss and meeting the ops requirements. Help appreciated :-)
Re: C++ compilation issue with command_rec
On Thu, 11 Dec 2003, Abdul Mujeer Kapadia wrote: invalid conversion from `const char*(*)(cmd_parms*, void*, const char*) ' to `const char*(*)()' Yeah, C++ doesn't like that kind of cast. Which is very annoying, but oh well. Not as annoying as some of the other things C++ won't let you do. :-) Anyway, why can't you just add an #ifdef __cplusplus block to the header file and change the command_rec to have the correct kind of prototype for the function pointer in question? --Cliff
new ETag supression/weakening API
hi all
this is something I've been meaning to do for a while. as mod_include
demonstrates, output filters will sometimes be required to remove the ETag
header generated by content handlers, depending on how much they alter the
content. the current methodology is to set a no-etag note, which is
recognized by the header filter.
what I wanted to do was expand this a bit and offer an ETag weakening API -
it should be easy to see that while some (most) output filters alter content
dramatically, others might only alter content bitwise but not semantically.
in these cases a weak etag is acceptable (and probably preferred to no etag
at all, from my reading of the specs). under the current state of affairs,
there is no way for an output filter to intercept ETag generation other than
to specify its removal.
the attached patch (etag_api.patch) offers two new functions.
ap_weaken_etag() guarantees a weak ETag header will be generated if one is
generated at all. the decision to generate one is still given to
ap_set_etag(). ap_supress_etag() is just a formalization of the no-etag
idiom into a real API.
fwiw, I've also included patches against mod_case_filter and the
perl-framework, which is what I used for my testing (so you can try it
yourself).
--Geoff
Index: include/http_protocol.h
===
RCS file: /home/cvspublic/httpd-2.0/include/http_protocol.h,v
retrieving revision 1.84
diff -u -r1.84 http_protocol.h
--- include/http_protocol.h 3 Feb 2003 17:52:53 - 1.84
+++ include/http_protocol.h 12 Dec 2003 16:57:17 -
@@ -196,11 +196,25 @@
AP_DECLARE(char *) ap_make_etag(request_rec *r, int force_weak);
/**
- * Set the E-tag outgoing header
+ * Set the ETag outgoing header
* @param The current request
* @deffunc void ap_set_etag(request_rec *r)
*/
AP_DECLARE(void) ap_set_etag(request_rec *r);
+
+/**
+ * Supress the ETag outgoing header
+ * @param The current request
+ * @deffunc void ap_supress_etag(request_rec *r)
+ */
+AP_DECLARE(void) ap_supress_etag(request_rec *r);
+
+/**
+ * Force generation of a weak ETag header
+ * @param The current request
+ * @deffunc void ap_weaken_etag(request_rec *r)
+ */
+AP_DECLARE(void) ap_weaken_etag(request_rec *r);
/**
* Set the last modified time for the file being sent
Index: modules/filters/mod_include.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.292
diff -u -r1.292 mod_include.c
--- modules/filters/mod_include.c 10 Dec 2003 02:30:20 - 1.292
+++ modules/filters/mod_include.c 12 Dec 2003 16:57:33 -
@@ -3584,7 +3584,7 @@
* We don't know if we are going to be including a file or executing
* a program - in either case a strong ETag header will likely be invalid.
*/
-apr_table_setn(f-r-notes, no-etag, );
+ap_supress_etag(f-r);
return OK;
}
Index: modules/http/http_protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.473
diff -u -r1.473 http_protocol.c
--- modules/http/http_protocol.c16 Nov 2003 02:09:13 - 1.473
+++ modules/http/http_protocol.c12 Dec 2003 16:57:37 -
@@ -2693,7 +2693,7 @@
* note it for the header-sender to ignore.
*/
if (etag_bits ETAG_NONE) {
-apr_table_setn(r-notes, no-etag, omit);
+ap_supress_etag(r);
return ;
}
@@ -2711,7 +2711,13 @@
* we send a weak tag instead of a strong one, since it could
* be modified again later in the second, and the validation
* would be incorrect.
+ *
+ * additional criteria for a weak tag is if force_weak is true
+ * or ap_weaken_etag() was called
*/
+
+force_weak = (force_weak || apr_table_get(r-notes, weak-etag));
+
if ((r-request_time - r-mtime (1 * APR_USEC_PER_SEC))
!force_weak) {
weak = NULL;
@@ -2831,6 +2837,37 @@
}
apr_table_setn(r-headers_out, ETag, etag);
+}
+
+/*
+ * Take steps to ensure that current and future-generated ETag
+ * headers are marked as weak.
+ */
+AP_DECLARE(void) ap_weaken_etag(request_rec *r)
+{
+const char *etag = apr_table_get(r-headers_out, ETag);
+
+/* if the ETag header exists and is not already marked
+ * as weak, mark it now
+ */
+if ((etag = apr_table_get(r-headers_out, ETag))
+strncmp(etag, ETAG_WEAK, strlen(ETAG_WEAK))) {
+
+ etag = apr_pstrcat(r-pool, ETAG_WEAK, etag, NULL);
+
+ apr_table_setn(r-headers_out, ETag, etag);
+}
+
+/* make sure future calls to ap_make_etag() produce weak tags */
+apr_table_setn(r-notes, weak-etag, yes);
+}
+
+/*
+ * Formalize ETag header supression.
+ */
+AP_DECLARE(void) ap_supress_etag(request_rec *r)
+{
+apr_table_setn(r-notes, no-etag, omit);
}
static int
ldap ssl authentication httpd 2, solaris 8
Anyone get this to work? Trying to compile apache on a solaris 8 machine with the cldap novell libraries that novell puts out for free with these configuration options: ./configure --with-prefix=/var/test --with-ssl=/afs/uncg.edu/@sys/opt/openssl --with-ldap-include=/usr/slocal/novell/include --with-ldap-lib=/usr/slocal/novell/lib --with-ldap --enable-ssl --enable-ldap --enable-auth-ldap Problem is of course, that this binary coredumps (did a gdb backtrace of it and it gets hung on an ldap parse statement. Even when removing the lines containing the cert file and the ldap stuff, it still core dumps). I compiled it with openssl libraries, but the problem if you compile with openldap libraries is that according to the code util_ldap.c, only BASE64_FILE is an acceptable type (not DER_FILE). I tried converting the DER file sent to me to pem format with openssl and apache didn't accept that file at startup. I know the DER file is fine since I use it in another application and can authenticate to the ldaps port fine with it. I can authenticate against ldap without using the secure port, but was wonder if anybody has been able to authenticate against the secure port using solaris8 version of apache 2.
Re: new ETag supression/weakening API
I just have a quick comment based on some work I did recently.
You should check for the ETag value in both headers_out locations.
It is actually a bit more likely that the ETag will be in r-err_headers_out
rather than r-headers_out, but it could be in either. Your patch should
look in both locations and stick the altered value back where you found it.
The other comment I have is that in the ap_weaken_etag function you call
etag = apr_table_get(r-headers_out, ETag) twice (once in the decl/init
and once in the conditional).
Other than that, I'm not enough of an expert on tags and weakness... from what
I do know this looks good, but some doc for the function might be useful to
help folks know when they might be legally able to weaken a tag.
Paul J. Reder
Geoffrey Young wrote:
hi all
this is something I've been meaning to do for a while. as mod_include
demonstrates, output filters will sometimes be required to remove the ETag
header generated by content handlers, depending on how much they alter the
content. the current methodology is to set a no-etag note, which is
recognized by the header filter.
what I wanted to do was expand this a bit and offer an ETag weakening API -
it should be easy to see that while some (most) output filters alter content
dramatically, others might only alter content bitwise but not semantically.
in these cases a weak etag is acceptable (and probably preferred to no etag
at all, from my reading of the specs). under the current state of affairs,
there is no way for an output filter to intercept ETag generation other than
to specify its removal.
the attached patch (etag_api.patch) offers two new functions.
ap_weaken_etag() guarantees a weak ETag header will be generated if one is
generated at all. the decision to generate one is still given to
ap_set_etag(). ap_supress_etag() is just a formalization of the no-etag
idiom into a real API.
fwiw, I've also included patches against mod_case_filter and the
perl-framework, which is what I used for my testing (so you can try it
yourself).
--Geoff
Index: include/http_protocol.h
===
RCS file: /home/cvspublic/httpd-2.0/include/http_protocol.h,v
retrieving revision 1.84
diff -u -r1.84 http_protocol.h
--- include/http_protocol.h 3 Feb 2003 17:52:53 - 1.84
+++ include/http_protocol.h 12 Dec 2003 16:57:17 -
@@ -196,11 +196,25 @@
AP_DECLARE(char *) ap_make_etag(request_rec *r, int force_weak);
/**
- * Set the E-tag outgoing header
+ * Set the ETag outgoing header
* @param The current request
* @deffunc void ap_set_etag(request_rec *r)
*/
AP_DECLARE(void) ap_set_etag(request_rec *r);
+
+/**
+ * Supress the ETag outgoing header
+ * @param The current request
+ * @deffunc void ap_supress_etag(request_rec *r)
+ */
+AP_DECLARE(void) ap_supress_etag(request_rec *r);
+
+/**
+ * Force generation of a weak ETag header
+ * @param The current request
+ * @deffunc void ap_weaken_etag(request_rec *r)
+ */
+AP_DECLARE(void) ap_weaken_etag(request_rec *r);
/**
* Set the last modified time for the file being sent
Index: modules/filters/mod_include.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.292
diff -u -r1.292 mod_include.c
--- modules/filters/mod_include.c 10 Dec 2003 02:30:20 - 1.292
+++ modules/filters/mod_include.c 12 Dec 2003 16:57:33 -
@@ -3584,7 +3584,7 @@
* We don't know if we are going to be including a file or executing
* a program - in either case a strong ETag header will likely be invalid.
*/
-apr_table_setn(f-r-notes, no-etag, );
+ap_supress_etag(f-r);
return OK;
}
Index: modules/http/http_protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.473
diff -u -r1.473 http_protocol.c
--- modules/http/http_protocol.c 16 Nov 2003 02:09:13 - 1.473
+++ modules/http/http_protocol.c 12 Dec 2003 16:57:37 -
@@ -2693,7 +2693,7 @@
* note it for the header-sender to ignore.
*/
if (etag_bits ETAG_NONE) {
-apr_table_setn(r-notes, no-etag, omit);
+ap_supress_etag(r);
return ;
}
@@ -2711,7 +2711,13 @@
* we send a weak tag instead of a strong one, since it could
* be modified again later in the second, and the validation
* would be incorrect.
+ *
+ * additional criteria for a weak tag is if force_weak is true
+ * or ap_weaken_etag() was called
*/
+
+force_weak = (force_weak || apr_table_get(r-notes, weak-etag));
+
if ((r-request_time - r-mtime (1 * APR_USEC_PER_SEC))
!force_weak) {
weak = NULL;
@@ -2831,6 +2837,37 @@
}
apr_table_setn(r-headers_out, ETag, etag);
+}
+
+/*
+ * Take steps to ensure that current
Re: new ETag supression/weakening API
Paul J. Reder wrote:
I just have a quick comment based on some work I did recently.
You should check for the ETag value in both headers_out locations.
It is actually a bit more likely that the ETag will be in
r-err_headers_out
rather than r-headers_out, but it could be in either.
hmm, I had thought about that. ap_meets_conditions only checks headers_out,
so I figured it was safe.
but you bring up an interesting point. outside of this patch, if somebody
manually populates an ETag header in err_headers_out then it won't be caught
by the no-etag stuff we already depend on. I'll account for that as well.
Your patch should
look in both locations and stick the altered value back where you found it.
yes, good idea. and it brings up another good point. the weaken API only
worked for tags generated with ap_make_etag - manual ETag entries could pass
through to the client unaltered if they happen after the new ap_weaken_etag
call. so, some additional logic is required in the header filter to take
care of those cases.
The other comment I have is that in the ap_weaken_etag function you call
etag = apr_table_get(r-headers_out, ETag) twice (once in the decl/init
and once in the conditional).
drat. refactoring leakage :)
Other than that, I'm not enough of an expert on tags and weakness...
from what
I do know this looks good, but some doc for the function might be useful to
help folks know when they might be legally able to weaken a tag.
sure. I placed a brief bit and a pointer to the docs in httpd.h, in
addition to expanding the comments in the weaken function more. is there
someplace else that's appropriate?
thanks for your input - new patch attached.
--Geoff
Index: include/http_protocol.h
===
RCS file: /home/cvspublic/httpd-2.0/include/http_protocol.h,v
retrieving revision 1.84
diff -u -r1.84 http_protocol.h
--- include/http_protocol.h 3 Feb 2003 17:52:53 - 1.84
+++ include/http_protocol.h 12 Dec 2003 19:03:00 -
@@ -196,11 +196,28 @@
AP_DECLARE(char *) ap_make_etag(request_rec *r, int force_weak);
/**
- * Set the E-tag outgoing header
+ * Set the ETag outgoing header
* @param The current request
* @deffunc void ap_set_etag(request_rec *r)
*/
AP_DECLARE(void) ap_set_etag(request_rec *r);
+
+/**
+ * Supress the ETag outgoing header
+ * @param The current request
+ * @deffunc void ap_supress_etag(request_rec *r)
+ */
+AP_DECLARE(void) ap_supress_etag(request_rec *r);
+
+/**
+ * Force generation of a weak ETag header.
+ * weak tags are allowed when the resource is semantically
+ * equivalent to a prior version, even though the content
+ * bits are different. see RFC-2616 13.3.3
+ * @param The current request
+ * @deffunc void ap_weaken_etag(request_rec *r)
+ */
+AP_DECLARE(void) ap_weaken_etag(request_rec *r);
/**
* Set the last modified time for the file being sent
Index: modules/filters/mod_include.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/filters/mod_include.c,v
retrieving revision 1.292
diff -u -r1.292 mod_include.c
--- modules/filters/mod_include.c 10 Dec 2003 02:30:20 - 1.292
+++ modules/filters/mod_include.c 12 Dec 2003 19:03:14 -
@@ -3584,7 +3584,7 @@
* We don't know if we are going to be including a file or executing
* a program - in either case a strong ETag header will likely be invalid.
*/
-apr_table_setn(f-r-notes, no-etag, );
+ap_supress_etag(f-r);
return OK;
}
Index: modules/http/http_protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.473
diff -u -r1.473 http_protocol.c
--- modules/http/http_protocol.c16 Nov 2003 02:09:13 - 1.473
+++ modules/http/http_protocol.c12 Dec 2003 19:03:18 -
@@ -1631,9 +1631,22 @@
/*
* Now remove any ETag response header field if earlier processing
* says so (such as a 'FileETag None' directive).
+ *
+ * be sure to clear err_headers_out, in case some non-core module
+ * populates it manually.
*/
if (apr_table_get(r-notes, no-etag) != NULL) {
apr_table_unset(r-headers_out, ETag);
+apr_table_unset(r-err_headers_out, ETag);
+}
+
+/* speaking of err_headers_out, if an ETag is added to either
+ * table manually, the ap_make_etag/ap_weaken_etag link is
+ * broken. do one final sweep to make sure we weaken the ETag
+ * no matter where it originated
+ */
+if (apr_table_get(r-notes, weak-etag) != NULL) {
+ap_weaken_etag(r);
}
/* determine the protocol and whether we should use keepalives. */
@@ -2693,7 +2706,7 @@
* note it for the header-sender to ignore.
*/
if (etag_bits ETAG_NONE) {
-apr_table_setn(r-notes, no-etag, omit);
+
Re: [PATCH] bug #18756 ldap cache and shared memory - cache init
I don't have a problem with this patch, but since NetWare doesn't use shared memory I am not able to trace down exactly what the issue is. Can you describe the circumstance where the util_ald_create_cache() function is called and st-cache_rmm is invalid? By simply looking through the code, it appeared that st-cache_rmm is always set before any call to util_ald_create_cache(). Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Thursday, December 11, 2003 1:51:49 AM Hi, st-cache_rmm is now invalid because due to non SHM plateform, bnicholes changed the alloc function util_ald_alloc to receive now util_ald_cache_t and no more apr_rmm_t. As we are just before the cache alloc, it's impossible to give util_ald_alloc a cache object, that's why there, i did a basic alloc functions. Jeff Trawick wrote: Matthieu Estrade wrote: Here is a little patch, fixing the ldap cache using shared memory. After the fix for plateform using SHM or not, it was a problem with cache init, unable to get it's rmm address to alloc memory. why is st-cache_rmm not filled out (or invalid)?
[PATCH] B21287, mutex protection in mod_mem_cache.c
Changes in decrement_refcount() and remove_url(). Patch extracted and modified from attachment in Bug 21285. The submitted patch was combining fix for 21285 and 21287. It is for decrement_refcount(). Alsoextended mutex protection in remove_url(). Thanks, Jean-Jacques mod_mem_cache.21287.patch Description: Binary data
Re: filtering huge request bodies (like 650MB files)
[we really should move this to the [EMAIL PROTECTED] list] On Fri, Dec 12, 2003 at 11:53:53AM +, Ben Laurie wrote: This was exactly the conversation we were having at the hackathon. As always, Windows was the problem, but I thought Bill had it licked? Well, there are two things we have to solve. I think we know how to solve the first one: portable IPC that works on Windows. This is not easy to solve in a portable way, but given enough energy I think this is solvable. The second part is getting all the different I/O types to work within the same poll() or poll-like mechanism. This seems like a much more difficult task to me, but it all depends on how it works under Windows. -aaron
Solaris/gdb/worker MPM hint to work around gdb problem
(gdb 5.0 or 6.0 on Solaris 9 x86, at least; not sure if it affects Solaris/Sparc) If you're having problems viewing threads after attaching to a threaded child process, hack the start_threads() function in worker.c to sleep instead of exit, then see if you can attach and debug successfully. Also, see gdb PR 1484 (go to http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=gdb and view the PR). Better hacks to worker or gdb probably aren't too hard.
(detabifyied) Re: [PATCH] B21287, mutex protection in mod_mem_cache.c
Just replaced tabswith spaces to follow guidelines. [EMAIL PROTECTED] 12/12/2003 1:23:20 PM Changes in decrement_refcount() and remove_url(). Patch extracted and modified from attachment in Bug 21285. The submitted patch was combining fix for 21285 and 21287. It is for decrement_refcount(). Alsoextended mutex protection in remove_url(). Thanks, Jean-Jacques mod_mem_cache.21287.patch Description: Binary data
Re: [PATCH] bug #18756 ldap cache and shared memory - cache init
Hi, I think my mail wasn't clear :) All is about the util_ald_alloc function using shm or not, st-cache_rmm is valid :) At the beginning, it was util_ald_alloc(unsigned long size) and inside, when the configure set APR_SHARED_MEMORY, it was using a global rmm_addr. Then, the patch i did was changing to util_ald_alloc (apr_rmm_t rmm_addr, unsigned long size), but with this, it was breaking the code on plateform without SHM. To make it work with non SHM plateform, Brad changed util_ald_alloc to util_ald_alloc(util_ald_cache_t *cache, unsigned long size) and inside, use cache-rmm_addr if SHM plateform. The problem happen at line 304 of util_ldap_cache_mgr.c, when it create the cache, it use util_ald_alloc, but it's unable to give the alloc function the cache data, because it's not created yet. Actually, it's : cache = (util_ald_cache_t *)util_ald_alloc(st-cache_rmm, sizeof(util_ald_cache_t)); This is broken, because the alloc function doesn't receive apr_rmm but util_ald_cache_t. that's why i did this alloc directly with the apr_rmm functions. Matthieu Brad Nicholes wrote: I don't have a problem with this patch, but since NetWare doesn't use shared memory I am not able to trace down exactly what the issue is. Can you describe the circumstance where the util_ald_create_cache() function is called and st-cache_rmm is invalid? By simply looking through the code, it appeared that st-cache_rmm is always set before any call to util_ald_create_cache(). Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Thursday, December 11, 2003 1:51:49 AM Hi, st-cache_rmm is now invalid because due to non SHM plateform, bnicholes changed the alloc function util_ald_alloc to receive now util_ald_cache_t and no more apr_rmm_t. As we are just before the cache alloc, it's impossible to give util_ald_alloc a cache object, that's why there, i did a basic alloc functions. Jeff Trawick wrote: Matthieu Estrade wrote: Here is a little patch, fixing the ldap cache using shared memory. After the fix for plateform using SHM or not, it was a problem with cache init, unable to get it's rmm address to alloc memory. why is st-cache_rmm not filled out (or invalid)?
(detabifyied) Re: [PATCH] Page Fault in mod_mem_cache-steaming response
Just replaced tabswith spaces to follow guidelines. [EMAIL PROTECTED] 12/11/2003 5:00:31 PM
Bugzilla Defect #21285
This is a rework of the already posted patch.
It address the following situation;
1- request comes in for streaming response
2- before that request could be completed, the entry is ejected from the cache
3- when completing the write body step, the incomplete entry is removed
before inserting the correct entry.
The problem is that the incomplete entry was already removed/replaced
in the cache. The cache_remove() will then seg fault.
I don't think it has something to do with the cache size has stated
in the bug description. I will follow with a patch removing the deprecated
cache_size and object_cnt from the mem_cache_conf struct.
@@ -1028,7 +1029,18 @@ if (sconf-lock) { apr_thread_mutex_lock(sconf-lock); }- cache_remove(sconf-cache_cache, obj);+ /* We need to check if the object has been removed/replaced + * from/in the cache, this could happen in some cases, because + * the current request is a streaming response that is handled + * in multiple individual pieces. - fixing Bugzilla Defect 21285+ */+ if((tmp_obj = (cache_object_t *) cache_find(sconf-cache_cache, obj-key)) + (tmp_obj == obj)) {+ cache_remove(sconf-cache_cache, obj);+ }+ else {+ obj-cleanup = 0;+ }
Iadded the patchtothe bug list of attachment.
Thank you,
Jean-Jacques
mod_mem_cache.21285.patch
Description: Binary data
Re: 2.0, Subrequest and Digest auth
On Fri, 12 Dec 2003, Sander Striker wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25040 Excelent ! Dw.
Re: new ETag supression/weakening API
thanks for your input - new patch attached. bah, that's not right either. I'll refactor it again and fix some of the messed up logic over the weekend. sorry to waste the bandwidth. --Geoff
