cookies generation by session, patch
Hi, I wrote a simple patch for 'Session.py'. Patch adds possibility to disable cookies generation by session. And it's optional. By default cookies generation enabled. Add Apache directive 'Python Option sessin_cookie_generation 0' for disabling. --- mod_python-3.2.8.orig/lib/python/mod_python/Session.py Mon Feb 20 00:51:18 2006 +++ mod_python-3.2.8/lib/python/mod_python/Session.py Tue Mar 21 09:50:46 2006 @@ -138,17 +138,19 @@ dict.__init__(self) session_cookie_name = req.get_options().get(session_cookie_name,COOKIE_NAME) +session_cookie_generation = int(req.get_options().get(session_cookie_generation,1)) if not self._sid: -# check to see if cookie exists -if secret: -cookies = Cookie.get_cookies(req, Class=Cookie.SignedCookie, - secret=self._secret) -else: -cookies = Cookie.get_cookies(req) +if session_cookie_generation: +# check to see if cookie exists +if secret: +cookies = Cookie.get_cookies(req, Class=Cookie.SignedCookie, + secret=self._secret) + else: +cookies = Cookie.get_cookies(req) -if cookies.has_key(session_cookie_name): -self._sid = cookies[session_cookie_name].value +if cookies.has_key(session_cookie_name): +self._sid = cookies[session_cookie_name].value if self._sid: # Validate the sid *before* locking the session @@ -171,7 +173,8 @@ if self._sid: self.unlock() # unlock old sid self._sid = _new_sid(self._req) self.lock() # lock new sid -Cookie.add_cookie(self._req, self.make_cookie()) +if session_cookie_generation: +Cookie.add_cookie(self._req, self.make_cookie()) self._created = time.time() if timeout: self._timeout = timeout
Re: cookies generation by session, patch
Now can you explain why one would want to do this? Unless you provide some justification of why it is necessary it is less likely to be accepted as although the reasons may be obvious to you, it may not be to us. There also may be better ways of achieving the same end. Also, describe why this would be better than simply deleting the cookie that is being created from the outgoing headers. del req.headers_out[Set-Cookie] Graham On 21/03/2006, at 7:39 PM, Stanislav Ershov wrote: Hi, I wrote a simple patch for 'Session.py'. Patch adds possibility to disable cookies generation by session. And it's optional. By default cookies generation enabled. Add Apache directive 'Python Option sessin_cookie_generation 0' for disabling. --- mod_python-3.2.8.orig/lib/python/mod_python/Session.py Mon Feb 20 00:51:18 2006 +++ mod_python-3.2.8/lib/python/mod_python/Session.py Tue Mar 21 09:50:46 2006 @@ -138,17 +138,19 @@ dict.__init__(self) session_cookie_name = req.get_options().get (session_cookie_name,COOKIE_NAME) +session_cookie_generation = int(req.get_options().get (session_cookie_generation,1)) if not self._sid: -# check to see if cookie exists -if secret: -cookies = Cookie.get_cookies(req, Class=Cookie.SignedCookie, - secret=self._secret) -else: -cookies = Cookie.get_cookies(req) +if session_cookie_generation: +# check to see if cookie exists +if secret: +cookies = Cookie.get_cookies(req, Class=Cookie.SignedCookie, + secret=self._secret) + else: +cookies = Cookie.get_cookies(req) -if cookies.has_key(session_cookie_name): -self._sid = cookies[session_cookie_name].value +if cookies.has_key(session_cookie_name): +self._sid = cookies[session_cookie_name].value if self._sid: # Validate the sid *before* locking the session @@ -171,7 +173,8 @@ if self._sid: self.unlock() # unlock old sid self._sid = _new_sid(self._req) self.lock() # lock new sid -Cookie.add_cookie(self._req, self.make_cookie()) +if session_cookie_generation: +Cookie.add_cookie(self._req, self.make_cookie()) self._created = time.time() if timeout: self._timeout = timeout
mod_python directory index error
Hi, i have a little problem about Directory Index. this is our .htaccess file: Allow from All AddHandler mod_python .py PythonHandler wepy.handler PythonDebug On DirectoryIndex index.htm index.html index.php index.py index.pl wepy is a new PHP like web python library. http://www.wepy.org/ we just type http://blablabla.com/wepy/ and our main file is index.py but req.path_info is None so in mod_python/apache.py/build_cgi_env function: if req.path_info and len(req.path_info) 0: env["SCRIPT_NAME"] = req.uri[:-len(req.path_info)] else: env["SCRIPT_NAME"] = req.uri i think should be like this. if req.path_info: env["SCRIPT_NAME"] = req.uri[:-len(req.path_info)] else: env["SCRIPT_NAME"] = req.uri regards -- Öğr. Gör. Fırat KÜÇÜK Industrial Electronics Program Coordinator --- Department of Industrial Electronics Sakarya University, Adapazari Vocational College + 90 (264) 346 02 32, fkucuk[at]sakarya[dot]edu[dot]tr http://www.adamyo.sakarya.edu.tr/ http://firat.kucuk.org/, firat[at]kucuk[dot]org ---
[jira] Created: (MODPYTHON-150) make_obcallback not thread protected
make_obcallback not thread protected Key: MODPYTHON-150 URL: http://issues.apache.org/jira/browse/MODPYTHON-150 Project: mod_python Type: Bug Components: core Versions: 3.2.8, 3.1.4 Reporter: Graham Dumpleton Assigned to: Graham Dumpleton In get_interpreter() function of src/mod_python.c the check of whether or not the callback object has been created is not within the bounds of the acquisition of the interpreters lock. As a result, in a multithreaded MPM, although the creation of the interpreter itself is protected so that only one thread will get to create it, multiple threads may decide the need to call make_obcallback(). In the past this hasn't mattered, but now that apache.init() is doing more complicated things, such as caching parameters as global variables and also doing fiddles with the callback object to allow optional use of new module importer, problems can start to arise. To fix the issue the release of the interpreters lock needs to be moved to the end of the get_interpreter() function. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MODPYTHON-150) make_obcallback not thread protected
[ http://issues.apache.org/jira/browse/MODPYTHON-150?page=all ] Work on MODPYTHON-150 started by Graham Dumpleton make_obcallback not thread protected Key: MODPYTHON-150 URL: http://issues.apache.org/jira/browse/MODPYTHON-150 Project: mod_python Type: Bug Components: core Versions: 3.2.8, 3.1.4 Reporter: Graham Dumpleton Assignee: Graham Dumpleton In get_interpreter() function of src/mod_python.c the check of whether or not the callback object has been created is not within the bounds of the acquisition of the interpreters lock. As a result, in a multithreaded MPM, although the creation of the interpreter itself is protected so that only one thread will get to create it, multiple threads may decide the need to call make_obcallback(). In the past this hasn't mattered, but now that apache.init() is doing more complicated things, such as caching parameters as global variables and also doing fiddles with the callback object to allow optional use of new module importer, problems can start to arise. To fix the issue the release of the interpreters lock needs to be moved to the end of the get_interpreter() function. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: mod_python directory index error
Firat KUCUK wrote .. Hi, i have a little problem about Directory Index. this is our .htaccess file: Allow from All AddHandler mod_python .py PythonHandlerwepy.handler PythonDebug On DirectoryIndex index.htm index.html index.php index.py index.pl wepy is a new PHP like web python library. http://www.wepy.org/ we just type http://blablabla.com/wepy/ and our main file is index.py but req.path_info is None so in mod_python/apache.py/build_cgi_env function: *if* req.path_info *and* len(req.path_info) 0: env[*SCRIPT_NAME*] = req.uri[:-len(req.path_info)] *else*: env[*SCRIPT_NAME*] = req.uri i think should be like this. if req.path_info: env[SCRIPT_NAME] = req.uri[:-len(req.path_info)] else: env[SCRIPT_NAME] = req.uri What is the actual problem you are trying to solve? The len(req.path_info) 0 is actually redundant because when req.path_info is a string and has length 0, the req.path_info boolean check will fail anyway. In other words, the change you made wouldn't make any difference that I can see to the actual outcome. Is the redundancy all you were wanting to point out??? BTW, you should be careful about what SCRIPT_NAME gets set to by Apache and by this code. See discussion of strange things that happen at: https://issues.apache.org/jira/browse/MODPYTHON-68 Graham
Re: cookies generation by session, patch
Now that I have some time, I'll explain why I want your reasoning. I didn't have the time when I sent original email. The only reason I can think of for Session not to generate a cookie is because the SID is being extracted from the URL or is being passed by some mechanism other than as a cookie. In this case the SID would need to be supplied explicitly when the Session object is being created: session = Session(req, sid=value) When a SID is supplied in this way, the Session object does not attempt to parse any cookies to get it. if not self._sid: # check to see if cookie exists if secret: cookies = Cookie.get_cookies(req, Class=Cookie.SignedCookie, secret=self._secret) else: cookies = Cookie.get_cookies(req) if cookies.has_key(session_cookie_name): self._sid = cookies[session_cookie_name].value Ie. only uses cookies to get it when self._sid evaluates False. Since if not using cookies but supplying the SID, the fact that this happens means that the change: if not self._sid: -# check to see if cookie exists -if secret: -cookies = Cookie.get_cookies(req, Class=Cookie.SignedCookie, - secret=self._secret) -else: -cookies = Cookie.get_cookies(req) +if session_cookie_generation: +# check to see if cookie exists +if secret: +cookies = Cookie.get_cookies(req, Class=Cookie.SignedCookie, + secret=self._secret) + else: +cookies = Cookie.get_cookies(req) is possibly redundant. I can't see any sense why if not supplying the SID that you would want to stop it reading the cookies as it probably wouldn't be useful. In respect of writing out a cookie, it could be argued that if you were supplying your own SID that it shouldn't assume that it should write the cookie. In that case though, rather than: -Cookie.add_cookie(self._req, self.make_cookie()) +if session_cookie_generation: +Cookie.add_cookie(self._req, self.make_cookie()) it possibly should be: if not sid: Cookie.add_cookie(self._req, self.make_cookie()) In other words, don't write out cookie if SID was supplied as input parameter. Thus, there wouldn't need to be a reason for a specific Python option to disable writing of cookie. So, can you explain what the original problem is you are trying to solve. On first appearances, your solution would seem to be going about it the wrong way. A question for others. Would it be reasonable that a cookie is not written out if SID was supplied explicitly? Graham Graham Dumpleton wrote .. Now can you explain why one would want to do this? Unless you provide some justification of why it is necessary it is less likely to be accepted as although the reasons may be obvious to you, it may not be to us. There also may be better ways of achieving the same end. Also, describe why this would be better than simply deleting the cookie that is being created from the outgoing headers. del req.headers_out[Set-Cookie] Graham On 21/03/2006, at 7:39 PM, Stanislav Ershov wrote: Hi, I wrote a simple patch for 'Session.py'. Patch adds possibility to disable cookies generation by session. And it's optional. By default cookies generation enabled. Add Apache directive 'Python Option sessin_cookie_generation 0' for disabling. --- mod_python-3.2.8.orig/lib/python/mod_python/Session.py Mon Feb 20 00:51:18 2006 +++ mod_python-3.2.8/lib/python/mod_python/Session.py Tue Mar 21 09:50:46 2006 @@ -138,17 +138,19 @@ dict.__init__(self) session_cookie_name = req.get_options().get (session_cookie_name,COOKIE_NAME) +session_cookie_generation = int(req.get_options().get (session_cookie_generation,1)) if not self._sid: -# check to see if cookie exists -if secret: -cookies = Cookie.get_cookies(req, Class=Cookie.SignedCookie, - secret=self._secret) -else: -cookies = Cookie.get_cookies(req) +if session_cookie_generation: +# check to see if cookie exists +if secret: +cookies = Cookie.get_cookies(req, Class=Cookie.SignedCookie, + secret=self._secret) + else: +cookies = Cookie.get_cookies(req) -if cookies.has_key(session_cookie_name): -self._sid = cookies[session_cookie_name].value +if
Re: cookies generation by session, patch
Graham Dumpleton wrote: Now that I have some time, I'll explain why I want your reasoning. I didn't have the time when I sent original email. The only reason I can think of for Session not to generate a cookie is because the SID is being extracted from the URL or is being passed by some mechanism other than as a cookie. In this case the SID would need to be supplied explicitly when the Session object is being created: session = Session(req, sid=value) When a SID is supplied in this way, the Session object does not attempt to parse any cookies to get it. if not self._sid: # check to see if cookie exists if secret: cookies = Cookie.get_cookies(req, Class=Cookie.SignedCookie, secret=self._secret) else: cookies = Cookie.get_cookies(req) if cookies.has_key(session_cookie_name): self._sid = cookies[session_cookie_name].value Ie. only uses cookies to get it when self._sid evaluates False. Since if not using cookies but supplying the SID, the fact that this happens means that the change: if not self._sid: -# check to see if cookie exists -if secret: -cookies = Cookie.get_cookies(req, Class=Cookie.SignedCookie, - secret=self._secret) -else: -cookies = Cookie.get_cookies(req) +if session_cookie_generation: +# check to see if cookie exists +if secret: +cookies = Cookie.get_cookies(req, Class=Cookie.SignedCookie, + secret=self._secret) + else: +cookies = Cookie.get_cookies(req) is possibly redundant. I can't see any sense why if not supplying the SID that you would want to stop it reading the cookies as it probably wouldn't be useful. In respect of writing out a cookie, it could be argued that if you were supplying your own SID that it shouldn't assume that it should write the cookie. In that case though, rather than: -Cookie.add_cookie(self._req, self.make_cookie()) +if session_cookie_generation: +Cookie.add_cookie(self._req, self.make_cookie()) it possibly should be: if not sid: Cookie.add_cookie(self._req, self.make_cookie()) In other words, don't write out cookie if SID was supplied as input parameter. Thus, there wouldn't need to be a reason for a specific Python option to disable writing of cookie. So, can you explain what the original problem is you are trying to solve. On first appearances, your solution would seem to be going about it the wrong way. A question for others. Would it be reasonable that a cookie is not written out if SID was supplied explicitly? The only advantage I can see is where the browser is set to notify the user every time a cookie is set, but those people must have gone crazy long ago anyway. On the other hand, explicit is better than implicit. On the other other hand, could there be application code out there that is setting the sid, but still making use of the cookie? If so, then the simple if not sid check would break their code. Unless Stanislav can give a good use case, I'd be inclined to leave things as is. Jim
Re: mod_python directory index error
Firat KUCUK wrote: Graham Dumpleton yazmış: Firat KUCUK wrote .. Hi, i have a little problem about Directory Index. this is our .htaccess file: Allow from All AddHandler mod_python .py PythonHandlerwepy.handler PythonDebug On DirectoryIndex index.htm index.html index.php index.py index.pl wepy is a new PHP like web python library. http://www.wepy.org/ we just type http://blablabla.com/wepy/ and our main file is index.py but req.path_info is None so in mod_python/apache.py/build_cgi_env function: *if* req.path_info *and* len(req.path_info) 0: env[*SCRIPT_NAME*] = req.uri[:-len(req.path_info)] *else*: env[*SCRIPT_NAME*] = req.uri i think should be like this. if req.path_info: env[SCRIPT_NAME] = req.uri[:-len(req.path_info)] else: env[SCRIPT_NAME] = req.uri What is the actual problem you are trying to solve? The len(req.path_info) 0 is actually redundant because when req.path_info is a string and has length 0, the req.path_info boolean check will fail anyway. In other words, the change you made wouldn't make any difference that I can see to the actual outcome. Is the redundancy all you were wanting to point out??? BTW, you should be careful about what SCRIPT_NAME gets set to by Apache and by this code. See discussion of strange things that happen at: https://issues.apache.org/jira/browse/MODPYTHON-68 Graham briefly: print len(None) TypeError: len() of unsized object if we use: if req.path_info *and* len(req.path_info) 0: the same error will be occur. Not in my python it doesn't. Python 2.3.5 (#2, Nov 20 2005, 16:40:39) [GCC 4.0.3 2005 (prerelease) (Debian 4.0.2-4)] on linux2 Type help, copyright, credits or license for more information. a = None if a and len(a) 0: ... print True ... else: ... print False ... False Perhaps you could show us the full traceback? Jim
[jira] Resolved: (MODPYTHON-150) make_obcallback not thread protected
[ http://issues.apache.org/jira/browse/MODPYTHON-150?page=all ] Graham Dumpleton resolved MODPYTHON-150: Fix Version: 3.3 Resolution: Fixed make_obcallback not thread protected Key: MODPYTHON-150 URL: http://issues.apache.org/jira/browse/MODPYTHON-150 Project: mod_python Type: Bug Components: core Versions: 3.2.8, 3.1.4 Reporter: Graham Dumpleton Assignee: Graham Dumpleton Fix For: 3.3 In get_interpreter() function of src/mod_python.c the check of whether or not the callback object has been created is not within the bounds of the acquisition of the interpreters lock. As a result, in a multithreaded MPM, although the creation of the interpreter itself is protected so that only one thread will get to create it, multiple threads may decide the need to call make_obcallback(). In the past this hasn't mattered, but now that apache.init() is doing more complicated things, such as caching parameters as global variables and also doing fiddles with the callback object to allow optional use of new module importer, problems can start to arise. To fix the issue the release of the interpreters lock needs to be moved to the end of the get_interpreter() function. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (MODPYTHON-93) Improve util.FieldStorage efficiency
[ http://issues.apache.org/jira/browse/MODPYTHON-93?page=all ] Jim Gallacher resolved MODPYTHON-93: Resolution: Fixed Improve util.FieldStorage efficiency Key: MODPYTHON-93 URL: http://issues.apache.org/jira/browse/MODPYTHON-93 Project: mod_python Type: Improvement Components: core Versions: 3.2.7 Reporter: Jim Gallacher Assignee: Jim Gallacher Priority: Minor Fix For: 3.3 Attachments: modpython325_util_py_dict.patch Form fields are saved as a list in a FieldStorage class instance. The class implements a __getitem__ method to provide dict-like behaviour. This method iterates over the complete list for every call to __getitem__. Applications that need to access all the fields when processing the form will show O(n^2) behaviour where n == the number of form fields. This overhead could be avoided by creating a dict (to use as an index) when the FieldStorage instance is created. Mike Looijmans has been investigating StringField and Field as well. It is probably reasonable to include information on his work in this issue as well, so that we can consider all of these efficiency issues in toto. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
mod_python 3.3.0-dev-20060321 available for testing
mod_python-3.3.0-dev-20060321 is available for testing.
We are asking the mod_python development community for assistance in
testing the current development branch. Hopefully this will allow us to
catch new bugs or regressions early, and when we are ready for the next
release the beta cycle will be much shorter.
This snapshot addresses 33 issues since 3.2.7 was released, including
apache 2.2 support and the introduction of a new module importer.
The files are (temporarily) available here:
http://people.apache.org/~jgallacher/mod_python/dist/
Please download it, then do the usual
$ ./configure --with-apxs=/wherever/it/is
$ make
$ (su)
# make install
Then (as non-root user!)
$ make check
or if you prefer to run the tests the old way:
$ cd test
$ python test.py
Make a note of any failing tests.
If all the tests pass, give the new module importer a workout by
uncommenting line 328 in test/test.py:
#PythonOption('mod_python.future.importer *'),
and then re-run the tests.
$ make check
And see if any tests fail. If they pass, send a +1 to the list, if they
fail, send the details (the versions of OS, Python and Apache, the test
output, and suggestions, if any).
Thank you for your assistance,
Jim Gallacher
Re: mod_python 3.3.0-dev-20060321 available for testing
I've tested with and without the new importer on Windows XP SP2 +
Python 2.4.2 + Apache 2.2.0 and everything works except the
test_req_auth_type test, which signals a 500 error. This is what the
error_log contains about this test :
[Wed Mar 22 07:16:03 2006] [warn] mod_python
(pid=5140,interpreter='test_req_auth_type'): Module directory listed
in sys.path. This may cause problems. Please check code. Code file
being imported is C:\\projets\\mod_python\\test\\htdocs\\tests.py.
[Wed Mar 22 07:16:03 2006] [notice] mod_python
(pid=5140,interpreter='test_req_auth_type'): Importing module
'C:\\projets\\mod_python\\test\\htdocs\\tests.py'
[Wed Mar 22 07:16:03 2006] [crit] [client 127.0.0.1] configuration
error: couldn't check access. No groups file?: /tests.py
[Wed Mar 22 07:16:03 2006] [error] [client 127.0.0.1] No Authn
provider configured
The piece of code that emits the No groups file? seem to reside in
libhttpd.dll, a part of Apache 2.2, so I guess it's a problem with my
Apache setup. I'll try this on my Apache 2.0 setup on my PC at work
and let you know.
Regards,
Nicolas
2006/3/22, Jim Gallacher [EMAIL PROTECTED]:
mod_python-3.3.0-dev-20060321 is available for testing.
We are asking the mod_python development community for assistance in
testing the current development branch. Hopefully this will allow us to
catch new bugs or regressions early, and when we are ready for the next
release the beta cycle will be much shorter.
This snapshot addresses 33 issues since 3.2.7 was released, including
apache 2.2 support and the introduction of a new module importer.
The files are (temporarily) available here:
http://people.apache.org/~jgallacher/mod_python/dist/
Please download it, then do the usual
$ ./configure --with-apxs=/wherever/it/is
$ make
$ (su)
# make install
Then (as non-root user!)
$ make check
or if you prefer to run the tests the old way:
$ cd test
$ python test.py
Make a note of any failing tests.
If all the tests pass, give the new module importer a workout by
uncommenting line 328 in test/test.py:
#PythonOption('mod_python.future.importer *'),
and then re-run the tests.
$ make check
And see if any tests fail. If they pass, send a +1 to the list, if they
fail, send the details (the versions of OS, Python and Apache, the test
output, and suggestions, if any).
Thank you for your assistance,
Jim Gallacher
[Patch] Backend reverse-proxy https connections
Right now, it appears that the backend https client is not correctly
initialized. Code inspection, based on my mod_ftp experience, is that
we aren't handshaking before sending our request. It's necessary for
the HTTPS client to do a 'pull' before pushing out the response to
handshake SSL/TLS, IIUC.
If it works at all, it's news to me :)
The attached patch should be correct to sync this up to mod_ftp and my
proposed mod_echo behavior. Comments?
Index: modules/proxy/mod_proxy_http.c
===
--- modules/proxy/mod_proxy_http.c (revision 387406)
+++ modules/proxy/mod_proxy_http.c (working copy)
@@ -1702,6 +1702,20 @@
if ((status = ap_proxy_connection_create(proxy_function, backend,
c, r-server)) != OK)
goto cleanup;
+
+if (backend-is_ssl) {
+apr_bucket_brigade *bb;
+bb = apr_brigade_create(c-pool, c-bucket_alloc);
+status = ap_get_brigade(c-input_filters, bb, AP_MODE_INIT,
+APR_BLOCK_READ, 0);
+apr_brigade_destroy(bb);
+
+if (status != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_ERR, status, r-server,
+ Failed to initialize the proxy ssl data stream);
+goto cleanup;
+}
+}
}
/* Step Four: Send the Request */
Re: svn commit: r386792 - /httpd/httpd/trunk/acinclude.m4
On Sat, Mar 18, 2006 at 02:26:21AM -, Justin Erenkrantz wrote: Author: jerenkrantz Date: Fri Mar 17 18:26:19 2006 New Revision: 386792 URL: http://svn.apache.org/viewcvs?rev=386792view=rev Log: * acinclude.m4: When enabling a static library, ensure that the module's dependent libraries are passed to the httpd link line. Some supported versions of GNU libtool as well as APR's jlibtool do not bubble-up static library dependencies. What supported versions of GNU libtool do this, what platform? Can you give a repro case so I can report this upstream? I've seen no reports of such problems with 2.2.x. Modified: httpd/httpd/trunk/acinclude.m4 Modified: httpd/httpd/trunk/acinclude.m4 URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/acinclude.m4?rev=386792r1=386791r2=386792view=diff == --- httpd/httpd/trunk/acinclude.m4 (original) +++ httpd/httpd/trunk/acinclude.m4 Fri Mar 17 18:26:19 2006 @@ -183,6 +183,9 @@ $libname: $objects \$(MOD_LINK) $objects $5 EOF + if test ! -z $5; then +APR_ADDTO(AP_LIBS, [$5]) + fi else apache_need_shared=yes libname=mod_$1.la
Re: apache-modules
Hey, On Mar 21, 2006, at 7:28 AM, William wrote: What is the url address to the apache-modules list. Thanks http://modules.apache.org/ No problemo. S. smime.p7s Description: S/MIME cryptographic signature
apache-modules
What is the url address to the apache-modules list. Thanks
Re: Log Program
So a Readline while not EOF should work then...I'll give that a shot.Jorge, keep in mind that the logger won't end until the write end of the pipeis closed, and that includes both the currently running workers, the parent,and it's own copy (!) if you kept one open. Be sure your logger only hasinherited the read end of the stream, once apache terminates you should beseeing eof on the read end.
Re: svn commit: r386792 - /httpd/httpd/trunk/acinclude.m4
On 3/21/06, Joe Orton [EMAIL PROTECTED] wrote: What supported versions of GNU libtool do this, what platform? 1.3 and 1.4 variants that are long unsupported or were tweaked incorrectly by the packager. The stock 1.5 series gets it right. Can you give a repro case so I can report this upstream? I've seen no reports of such problems with 2.2.x. It also happens with APR's jlibtool - which was the specific case I'm interested in. *shrug* -- justin
2.2.1?
Hello. I just wondered to know when you plan to release apache-2.2.1+? -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
Bug in proxy_balancer?
This works: VirtualHost * ... Proxy balancer://fill BalancerMember http://server1:80 route=server1 BalancerMember http://server2:80 route=server2 /Proxy ProxyPass /path balancer://fill/ stickysession=Sticky /VirtualHost This does not: Proxy balancer://fill BalancerMember http://server1:80 route=server1 BalancerMember http://server2:80 route=server2 /Proxy VirtualHost * ... ProxyPass /path balancer://fill/ stickysession=Sticky /VirtualHost I want to be able to use same balancer in multiple vhosts. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Bug in proxy_balancer?
got bounced? Original Message Subject: Bug in proxy_balancer? Date: Tue, 21 Mar 2006 14:18:07 -0500 From: Brian Akins [EMAIL PROTECTED] To: dev@httpd.apache.org This works: VirtualHost * ... Proxy balancer://fill BalancerMember http://server1:80 route=server1 BalancerMember http://server2:80 route=server2 /Proxy ProxyPass /path balancer://fill/ stickysession=Sticky /VirtualHost This does not: Proxy balancer://fill BalancerMember http://server1:80 route=server1 BalancerMember http://server2:80 route=server2 /Proxy VirtualHost * ... ProxyPass /path balancer://fill/ stickysession=Sticky /VirtualHost I want to be able to use same balancer in multiple vhosts. -- Brian Akins Lead Systems Engineer CNN Internet Technologies -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: Appeal for help understanding fiendishly complex data structure in mod_authz_core
{ On 3/19/2006 at 8:40:56 am, in message [EMAIL PROTECTED],
[EMAIL PROTECTED]
wrote:
mod_authz_core contains a fiendishly complex data structure, the
'authz_provider_list' (which is actually more like a tree than a list),
which is used to implement the concept of nested
SatisfyOne/SatisfyAll sections.
I've been trying off-and-on for about a week to understand this
structure, and the code that creates and walks it, but have been
unsuccessful.
I'm sending this email as an appeal for assistance understanding this
code, and also as an alert that this code may prove to be a potential
maintenance problem, if it is so difficult to comprehend.
Thanks,
Max.
You are right, the piece of code that traverses the SatisfyOne/All list is a
bit complex which is the reason why I tried to document it well according to
what the code is doing. If I could have made this code simpler, obviously I
would have. The basic concept behind the code as I see it, is a list that
grows horizontally or vertically with each nested state change (ie. one vs
all). The only other component that is tracked while the list (or tree) is
being traversed is the nesting level. The nesting level simply indicates how
many state changes have occurred within a given path from the root node to the
leaf node. I'm not sure that I can explain the code much better through an
email than is already explained in the comments and source code that exist in
the add_authz_provider() or check_provider_list() functions. When adding a
node to the list, the idea is to follow the nesting path until a leaf node is
encountered and then add the new node to the leaf node depending on whether the
new node maintains the same state or introduces a state change. When checking
the provider list, each provider in the list must be satisfied according to
it's state and boolean logic.
Brad
[PATCH] add proxy balancer support to ProxyRemote
Hi, This patch provides load balancing support for remote proxy servers. Scenario: Proxy balancer://cluster/ BalancerMember http://cache1.foo.bar BalancerMember http://cache2.foo.bar BalancerMember http://cache3.foo.bar /Proxy VirtualHost *:8000 ProxyRemote * balancer://cluster/ /VirtualHost Mergeable ? Thanks, Davi Arnaut ProxyRemote-Balancer.patch Description: Binary data
Using Output Filter
Hi I am new to Apache and I am not sure if I have set up correctly. I have Apache running on my computer as a Proxy server using the directive ProxyRequest On. I created a module as an Output filter for .html, .txt, .css and .js files. I have configured my browser to use the Apache Proxy server running on my computer. When I surf the internet the Apche HTTP proxy module is getting triggered so, I know that the request are going through Apache. I have added the AddOutputFilter directive so that I can use my Output filter module. The problem is when I open a web page typing in an url (i.e. ww.msn.com) in my browser. my output filter module is not being triggered, I cannot filter the response from the orgin server. If I type http://localhost I get a blank page which I should but, my output filter module gets triggered. How should I be setup so that I can filter the http response context before it is displayed in my web browser.
SSL_CLIENT_CERT header bad format
It seems that the PEM-encoded certificate coming out of OpenSSL (0.9.8a in
my case) contains new lines without leading space, which is interpreted as a
new HTTP header.
Even more important, the last empty line leads to 2 new lines without
leading space, which is interpreted as the end of all HTTP headers.
This could be fixed by removing all new lines in the PEM-encoded
certificate, in ssl_engine_vars.c:
static char *ssl_var_lookup_ssl_cert_PEM(apr_pool_t *p, X509 *xs)
{
...
BIO_free(bio);
+ /* remove all new lines (CR LF) */
+ {
+ char *source, *target;
+ for ( source = target = result; *source; source++ ) {
+ if ( (*source != 0x0A) (*source != 0x0D) ) *target++ = *source;
+ }
+ *target = NUL;
+ }
return result;
}
Remark: the test
if ( (*source != 0x0A) (*source != 0x0D) )
could also be replaced by a more general one:
if ( *source = ' ' )
