Re: svn commit: r280884 - /httpd/mod_aspdotnet/trunk/mod/mod_aspdotnet.cpp
W. Rowe wrote Ping(!) Would appreciate if anyone would try testing this release and replying on-list if virtual, files in fact really are working. If not I'll pull down the snapshot, if so I'll move forward on 'AspNet error' to bypass Apache ErrorDocument handling. Adrian says This fixed the problem I had with error pages, which was that the default ASP.NET generated page for customErrors mode=On / was being served up just fine, but the more detailed page with stack trace for customErrors mode=Off / was being replaced with the default Apache ErrorDocument. I don't have any ErrorDocument values explicitly defined. The ASP.NET page with stack trace is now served properly, given juicy stacktrace goodness to those people debugging. With customErrors mode=On defaultRedirect=BadThings.htm /, BadThings.htm is also served correctly. Don't know about virtual files though (are the error pages examples of these?), but you fixed something real good...
NTLM authentication using mod_auth_sspi fails
Using mod_auth_sspi results in an exception in the WindowsIdentity class. The user token is being sourced from the System.Web.Hosting.SimpleWorkerRequest class which returns a null pointer from the GetUserToken() method. The ISAPIWorkerRequestInProc and ISAPIWorkerRequestOutOfProc classes (same namespace) may or may not be appropriate replacements. Or perhaps use the aspnet_isapi.dll methods EcbGetImpersonationToken or PMGetImpersonationToken (in and out of process calls, repectively), which are exposed also by the System.Web.UnsafeNativeMethods class. Would just like to be able to avoid having to school my users in yet another user/password combo, and just stick with NTLM as it's what they are used to for their Subversion repo and Trac. # Exception stack trace [ArgumentException: Token cannot be zero.] System.Security.Principal.WindowsIdentity.CreateFromToken(IntPtr userToken, String type, Boolean bClose) +145 System.Security.Principal.WindowsIdentity..ctor(IntPtr userToken, String type, WindowsAccountType acctType, Boolean isAuthenticated) +38 System.Web.Security.WindowsAuthenticationModule.OnEnter(Object source, EventArgs eventArgs) +372 System.Web.SyncEventExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute() +51 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean completedSynchronously) +87 ## httpd.conf #asp.net #AspNetVersion v1.1.4322 LoadModule aspdotnet_module modules/mod_aspdotnet.so AddHandler asp.net asax ascx ashx asmx aspx axd config cs csproj licx rem resources resx soap vb vbproj vsdisco webinfo IfModule mod_aspdotnet.cpp # Mount the ASP.NET /asp application AspNetMount /arty d:/www/localhost/htdocs/arty #/SampleASP is the alias name for asp.net to execute #c:/SampleASP is the actual execution of files/folders in that location # Map all requests for /asp to the application files Alias /arty d:/www/localhost/htdocs/arty #maps /SampleASP request to c:/SampleASP #now to get to the /SampleASP type http://localhost/SampleASP #It'll redirect http://localhost/SampleASP to c:/SampleASP # Allow asp.net scripts to be executed in the /SampleASP example Directory d:/www/localhost/htdocs/arty Options FollowSymlinks ExecCGI Order allow,deny AuthType SSPI AuthName aspx SSPIAuth On SSPIAuthoritative On SSPIOfferBasic On require valid-user Allow from all DirectoryIndex index.htm index.aspx #default the index page to .htm and .aspx /Directory # For all virtual ASP.NET webs, we need the aspnet_client files # to serve the client-side helper scripts. AliasMatch /aspnet_client/system_web/(\d+)_(\d+)_(\d+)_(\d+)/(.*) \ C:/Windows/Microsoft.NET/Framework/v$1.$2.$3/ASP.NETClientFiles/$4 Directory \ C:/Windows/Microsoft.NET/Framework/v*/ASP.NETClientFiles Options FollowSymlinks Order allow,deny Allow from all /Directory /IfModule #asp.net
[jira] Commented: (MODPYTHON-77) The multiple interpreter concept of mod_python is broken for Python extension modules since Python 2.3
[ http://issues.apache.org/jira/browse/MODPYTHON-77?page=comments#action_12356765 ] Graham Dumpleton commented on MODPYTHON-77: --- Just to make this problem even more complicated, due to how Mac OS X handles unloading of dynamically loaded modules, parts of the solution presented here so far may not actually work on that platform. On Mac OS X, if one takes the initial basic solution of storing the first interpreter as the main_interpreter and nothing else, the original problem goes away, however, Apache will crash when apachectl restart is run. The problem is that when a restart occurs, Apache doesn't actually kill the parent process. What it does is to unload any loaded Apache modules, such as mod_python.so and then it will be reload them again. This results in all global data within mod_python.so being thrown away. The python_init() function of the mod_python.so will be called again to reinitialise all the lost global data and start over, but it fails in doing this. The reason it fails is that although mod_python.so is unloaded, the dynamically loaded Python framework isn't. The first consequence of this is that when calling python_init() the subsequent time, the Python framework is already initialised. Due to a previous workaround incorporated into python_init() specifically because of Mac OS X, this luckily doesn't stop us from at least trying to initialise mod_python again. In initialising mod_python though, because the previous global data is lost, we need to store the initial interpreter state against main_interpreter again. To do this, PyThreadState_Get()-interp is used. For this to work though, it is necessary that the call to PyEval_InitThreads() just prior to that point in the code has acquired the global lock and set up a current thread state. This will only occur though for the very first call to PyEval_InitThreads(). Because the Python framework isn't unloaded and Python thus is already in an initialised state, the PyEval_InitThreads() call doesn't do anything. Because there is no valid active thread state, the call to PyThreadState_Get() fails. One can see this when some extra debugging is added to mod_python. For Mac OS X we get: # apachectl start [Fri Nov 04 20:50:17 2005] [notice] mod_python: Creating 8 session mutexes based on 6 max processes and 25 max threads. [Fri Nov 04 20:50:17 2005] [error] mp_initialized=0 [Fri Nov 04 20:50:17 2005] [error] Py_IsInitialized()=0 [Fri Nov 04 20:50:17 2005] [error] interpreters=0 [Fri Nov 04 20:50:18 2005] [error] save interpreter [Fri Nov 04 20:50:18 2005] [error] pid=805 [Fri Nov 04 20:50:18 2005] [error] ppid=1 [Fri Nov 04 20:50:18 2005] [error] done save interpreter [Fri Nov 04 20:50:18 2005] [error] get thread state [Fri Nov 04 20:50:18 2005] [error] okay got thread state [Fri Nov 04 20:50:18 2005] [error] released interpreter [Fri Nov 04 20:50:18 2005] [notice] Apache/2.0.51 (Unix) mod_python/3.2.4b Python/2.3 configured -- resuming normal operations # apachectl restart [Fri Nov 04 20:50:26 2005] [warn] child process 807 still did not exit, sending a SIGTERM [Fri Nov 04 20:50:27 2005] [notice] SIGHUP received. Attempting to restart [Fri Nov 04 20:50:27 2005] [notice] mod_python: Creating 8 session mutexes based on 2 max processes and 25 max threads. [Fri Nov 04 20:50:27 2005] [error] mp_initialized=0 [Fri Nov 04 20:50:27 2005] [error] Py_IsInitialized()=1 [Fri Nov 04 20:50:27 2005] [error] interpreters=0 [Fri Nov 04 20:50:27 2005] [error] save interpreter [Fri Nov 04 20:50:27 2005] [error] pid=805 [Fri Nov 04 20:50:27 2005] [error] ppid=1 Fatal Python error: PyThreadState_Get: no current thread [Fri Nov 04 20:50:27 2005] [notice] seg fault or similar nasty error detected in the parent process You can see how it is the same process ID, that Python is already marked as initailised, yet interpreters and the initialized flag which were global data in mod_python.so have gone back to being 0. Finally, the PyThreadState_Get() function dies. If one looks at Linux, one instead sees: # apachectl start [Fri Nov 04 05:22:46 2005] [notice] mod_python: Creating 8 session mutexes based on 150 max processes and 0 max threads. [Fri Nov 04 05:22:46 2005] [error] mp_initialized=0 [Fri Nov 04 05:22:46 2005] [error] Py_IsInitialized()=0 [Fri Nov 04 05:22:46 2005] [error] interpreters=0 [Fri Nov 04 05:22:46 2005] [error] save interpreter [Fri Nov 04 05:22:46 2005] [error] pid=8757 [Fri Nov 04 05:22:46 2005] [error] ppid=1 [Fri Nov 04 05:22:46 2005] [error] done save interpreter [Fri Nov 04 05:22:46 2005] [error] get thread state [Fri Nov 04 05:22:46 2005] [error] okay got thread state [Fri Nov 04 05:22:46 2005] [error] released interpreter [Fri Nov 04 05:22:46 2005] [notice] Apache/2.0.55 (Unix) mod_python/3.2.4b Python/2.3.5 configured -- resuming normal operations # apachectl restart [Fri Nov 04 05:22:55 2005] [notice] SIGHUP received. Attempting to restart [Fri
[jira] Updated: (MODPYTHON-77) The multiple interpreter concept of mod_python is broken for Python extension modules since Python 2.3
[ http://issues.apache.org/jira/browse/MODPYTHON-77?page=all ]
Graham Dumpleton updated MODPYTHON-77:
--
Attachment: grahamd_20051105.tar.gz
Here is my first go at an alternate patch for this problem. Patch was made
against SVN head, believed to be 3.2.4b.
All the change in effect does is save the first interpreter as
main_interpreter, but most importantly it does this in Apache child process and
not in the parent process before the fork occurs as was the case before. This
avoids problems on Mac OS X where Apache would crash on restart and on Linux
where Apache would crash after the request had been handled.
Note that this change doesn't use any of the PEP GIL specific calls nor does it
do anything specific to make anything work on Python 2.3.5. Except for moving
one thread state swap call from the parent process context to the child process
context, all thread management code is the same.
The changes work fine on:
Mac OS X (10.3.9) / Apache 2.0.51 (worker) / Python 2.3 (Apple OS Installed)
Linux Fedora Code 2 / Apache 2.0.55 (prefork) / Python 2.3.5
Test example was gilstate.tar.gz attached to MODPYTHON-77.
Also passed on mod_python/test suite on Mac OS X. There were failures of test
suite on Linux, but those failures occurred before patches were applied as well.
The changes need to be tested on Win32 Apache as well as system where no thread
support compiled into Python.
For those of you following this issue, if you can test this change, indicate if
it works or fails and if it fails indicate specifically how it is failing. From
any failures can then start to understand the other changes Boyan has made and
what is required and what isn't.
The multiple interpreter concept of mod_python is broken for Python extension
modules since Python 2.3
--
Key: MODPYTHON-77
URL: http://issues.apache.org/jira/browse/MODPYTHON-77
Project: mod_python
Type: Bug
Components: core
Versions: 3.1.4
Environment: Python = 2.3
Reporter: Boyan Boyadjiev
Attachments: diff.txt, diff2.txt, diff3.txt, gil_test.c, gilstate.tar.gz,
grahamd_20051105.tar.gz, mod_python.c, mod_python.c.diff, mod_python.h.diff,
src.zip
The multiple interpreter concept of mod_python is broken for Python extension
modules since Python 2.3 because of the PEP 311 (Simplified Global
Interpreter Lock Acquisition for Extensions):
...
Limitations and Exclusions
This proposal identifies a solution for extension authors with
complex multi-threaded requirements, but that only require a
single PyInterpreterState. There is no attempt to cater for
extensions that require multiple interpreter states. At the time
of writing, no extension has been identified that requires
multiple PyInterpreterStates, and indeed it is not clear if that
facility works correctly in Python itself.
...
For mod_python this means, that complex Python extensions won't work any more
with Python = 2.3, because they are supposed to work only with the first
interpreter state initialized for the current process (a problem we
experienced). The first interpreter state is not used by mod_python after the
python_init is called.
One solution, which works fine for me, is to save the first interpreter state
into the interpreters dictionary in the function python_init
(MAIN_INTERPRETER is used as a key):
static int python_init(apr_pool_t *p, apr_pool_t *ptemp,
apr_pool_t *plog, server_rec *s)
{
...
/* initialize global Python interpreter if necessary */
if (! Py_IsInitialized())
{
/* initialze the interpreter */
Py_Initialize();
#ifdef WITH_THREAD
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
/* create the obCallBack dictionary */
interpreters = PyDict_New();
if (! interpreters) {
ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, s,
python_init: PyDict_New() failed! No more memory?);
exit(1);
}
{
/*
Workaround PEP 311 - Simplified Global Interpreter Lock
Acquisition for Extensions
BEGIN
*/
PyObject *p = 0;
interpreterdata * idata = (interpreterdata
*)malloc(sizeof(interpreterdata));
PyThreadState* currentThreadState = PyThreadState_Get();
PyInterpreterState *istate = currentThreadState-interp;
idata-istate = istate;
/* obcallback will be created on first use */
idata-obcallback = NULL;
p = PyCObject_FromVoidPtr((void ) idata, NULL); /*p-refcout = 1*/
PyDict_SetItemString(interpreters, MAIN_INTERPRETER, p);
/*p-refcout = 2*/
Re: Potential memory leak in /modules/cache/mod_mem_cache.c
So, same reason. Also in file mod_mem_cache.c around line 786, there is a malloc(mobj-m_len), and a few lines later, another malloc(obj-count) is performed. If the second malloc fails, I think also should add something like free(mobj-m); mobj-m = NULL; reasonable? Thx, Xuekun On 11/3/05, Bill Stoddard [EMAIL PROTECTED] wrote: Christophe Jaillet wrote: Comments agains httpd-2.1.8-beta = In file mod_mem_cache.c (/modules/cache) around line 558, there is a malloc (*obj). A few lines later, another malloc (buf) is performed. If the second malloc fails, then we have (*obj = NULL) but I don't see anyway to free the memory allocated. I would have imagined something like free (*obj); *obj = NULL; Unless, as a newbie in apache, there is something I don't know about memory management in apache... Christophe JAILLET Agreed, looks like a bug and your fix looks right. Bill
Re: SSL enabled - nokeepalive in MSIE for non-SSL connections
On Thu, Nov 03, 2005 at 03:37:10PM +0100, Olaf van der Spek wrote: Joe Orton wrote: All versions need unclean shutdown at least, not sure about keepalive. If you have new data to provide on this front that's great and very welcome, please send it to [EMAIL PROTECTED] bugzilla is not a discussion or support forum, however. I've been running without SetEnvIf User-Agent .*MSIE.* \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 for a few months now and I haven't encountered any issues with IE. So I think it's safe to drop this work around. Intesting to hear, thanks. What range of MSIE versions are hitting your SSL site? joe
Re: authn, authz and access. oh my.
Brandon Fosdick wrote: Noobie question...what's the difference between authentication, authorization and access? Authentication asks is this user who they say they are, this stage usually involves a username and password of some sort, or a certificate, etc. Authorisation asks is this user allowed to access this resource. Here the require directive specifies whether just being known to the system is enough, or whether further group membership is required. From a module perspective these two tasks are handled in two separate steps. Usually the second step relies on the first step, but it is still possible to be authenticated by one module (for example, an SSL certificate) and authorised by another module (for example, checking if the certificate DN is a member of an LDAP group). Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Problem with mod_proxy and ProxyPassReverse
Eric B. wrote: # Production Server Location /ASPTest/ ProxyPassReverse / /Location ProxyPass /ASPTest/ http://192.168.100.1/ # Development Test Server Location /dev/ASPTest/ ProxyPassReverse / /Location ProxyPass /dev/ASPTest/ http://192.168.100.1:8080/ Unless you are trying to do something special, the ProxyPassReverse lines should look like this: ProxyPassReverse /ASPTest/ http://192.168.100.1/ ProxyPass/ASPTest/ http://192.168.100.1/ # Development Test Server ProxyPassReverse /dev/ASPTest/ http://192.168.100.1:8080/ ProxyPass/dev/ASPTest/ http://192.168.100.1:8080/ Make sure that your backend webservers agree that they are called http://192.168.100.1:8080;, otherwise ProxyPassReverse won't do anything. The ProxyPassReverse is a simple find and replace string match on the prefix of the URL returned by the backend server during redirects. You had this prefix set to /, which won't match http://...;. Another problem you may have is if hard coded references to the full site name are hard coded into your backend application. Proxy does not parse HTML, and so doesn't try any of the same find and replace magic inside the HTML itself. If this is the case, either remove the references to the full site name from the backend, or introduce a mechanism to make sure the backend embeds the frontend world visible URL into the pages instead of your private http://192.168.0.1 URL. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: SSL enabled - nokeepalive in MSIE for non-SSL connections
On 11/4/05, Joe Orton [EMAIL PROTECTED] wrote: On Thu, Nov 03, 2005 at 03:37:10PM +0100, Olaf van der Spek wrote: Joe Orton wrote: All versions need unclean shutdown at least, not sure about keepalive. If you have new data to provide on this front that's great and very welcome, please send it to [EMAIL PROTECTED] bugzilla is not a discussion or support forum, however. I've been running without SetEnvIf User-Agent .*MSIE.* \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 for a few months now and I haven't encountered any issues with IE. So I think it's safe to drop this work around. Intesting to hear, thanks. What range of MSIE versions are hitting your SSL site? It's only a small SSL site, used for administration tasks by a few people. I've been using the latest versions of IE6 so based on that I know the issue doesn't affect all IE versions (while the SetEnvIf matches all versions).
[jira] Commented: (MODPYTHON-77) The multiple interpreter concept of mod_python is broken for Python extension modules since Python 2.3
[
http://issues.apache.org/jira/browse/MODPYTHON-77?page=comments#action_12356757
]
Boyan Boyadjiev commented on MODPYTHON-77:
--
Sorry - I didn't saw the change done for MODPYTHON-83. PyThreadState_Swap must
be added in the non thread case of release_interpreter.
With smallest required change I just wanted to say, that if the GIL stuff is
not going to be used in mod_python, there is still somehing to do in order to
handle the Python thread state in a proper way since Python 2.3.5.
I think, that the most proper fix will be mod_python.?.diff +
PyThreadState_Swap.
Now a different point regarding internal_redirect. What will hapen if
interpreter1 call internal_redirect into interpreter2? Could it be, that the
block
Py_BEGIN_ALLOW_THREADS
ap_internal_redirect(new_uri, self-request_rec);
Py_END_ALLOW_THREADS
is not sofficient any more and should be changed in something like this
release_interpreter
ap_internal_redirect(new_uri, self-request_rec);
get_interpreter
The multiple interpreter concept of mod_python is broken for Python extension
modules since Python 2.3
--
Key: MODPYTHON-77
URL: http://issues.apache.org/jira/browse/MODPYTHON-77
Project: mod_python
Type: Bug
Components: core
Versions: 3.1.4
Environment: Python = 2.3
Reporter: Boyan Boyadjiev
Attachments: diff.txt, diff2.txt, diff3.txt, gil_test.c, gilstate.tar.gz,
mod_python.c, mod_python.c.diff, mod_python.h.diff, src.zip
The multiple interpreter concept of mod_python is broken for Python extension
modules since Python 2.3 because of the PEP 311 (Simplified Global
Interpreter Lock Acquisition for Extensions):
...
Limitations and Exclusions
This proposal identifies a solution for extension authors with
complex multi-threaded requirements, but that only require a
single PyInterpreterState. There is no attempt to cater for
extensions that require multiple interpreter states. At the time
of writing, no extension has been identified that requires
multiple PyInterpreterStates, and indeed it is not clear if that
facility works correctly in Python itself.
...
For mod_python this means, that complex Python extensions won't work any more
with Python = 2.3, because they are supposed to work only with the first
interpreter state initialized for the current process (a problem we
experienced). The first interpreter state is not used by mod_python after the
python_init is called.
One solution, which works fine for me, is to save the first interpreter state
into the interpreters dictionary in the function python_init
(MAIN_INTERPRETER is used as a key):
static int python_init(apr_pool_t *p, apr_pool_t *ptemp,
apr_pool_t *plog, server_rec *s)
{
...
/* initialize global Python interpreter if necessary */
if (! Py_IsInitialized())
{
/* initialze the interpreter */
Py_Initialize();
#ifdef WITH_THREAD
/* create and acquire the interpreter lock */
PyEval_InitThreads();
#endif
/* create the obCallBack dictionary */
interpreters = PyDict_New();
if (! interpreters) {
ap_log_error(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, 0, s,
python_init: PyDict_New() failed! No more memory?);
exit(1);
}
{
/*
Workaround PEP 311 - Simplified Global Interpreter Lock
Acquisition for Extensions
BEGIN
*/
PyObject *p = 0;
interpreterdata * idata = (interpreterdata
*)malloc(sizeof(interpreterdata));
PyThreadState* currentThreadState = PyThreadState_Get();
PyInterpreterState *istate = currentThreadState-interp;
idata-istate = istate;
/* obcallback will be created on first use */
idata-obcallback = NULL;
p = PyCObject_FromVoidPtr((void ) idata, NULL); /*p-refcout = 1*/
PyDict_SetItemString(interpreters, MAIN_INTERPRETER, p);
/*p-refcout = 2*/
Py_DECREF(p); /*p-refcout = 1*/
/*
END
Workaround PEP 311 - Simplified Global Interpreter Lock
Acquisition for Extensions
*/
}
/* Release the thread state because we will never use
* the main interpreter, only sub interpreters created later. */
PyThreadState_Swap(NULL);
#ifdef WITH_THREAD
/* release the lock; now other threads can run */
PyEval_ReleaseLock();
#endif
}
return OK;
}
Another change I've made in the attached file is to Py_DECREF(p) in
get_interpreter, which will remove leaky reference to the PyCObject with the
interpreter data. This was not a real problem, but now
Re: svn commit: r227435 - in /httpd/httpd/branches/2.0.x: CHANGES STATUS modules/proxy/proxy_util.c
Anyone?
* Andr__ Malo [EMAIL PROTECTED] wrote:
* [EMAIL PROTECTED] wrote:
Author: jim
Date: Thu Aug 4 10:07:57 2005
New Revision: 227435
URL: http://svn.apache.org/viewcvs?rev=227435view=rev
Log:
mod_proxy: Fix over-eager handling of '%' for reverse proxies. PR 29554.
Note that this patch broke certain RewriteRules out there, which proxy URLs
with path parameters (http://foo/bar;param?query). It might be questionable
if the Rules were written wrong in the first place, but they are broken by
the update to 2.0.55 now.
For example, I have something like this (shortened):
RewriteMap e int:escape
RewriteRule ^/+(.*) \
http://backend/${e:$1}?i=${e:%{REMOTE_ADDR}}%{ENV:NEW_QUERY} [P,NE]
If $1 contains a ';', it is escaped by the map to %3B but no longer
unescaped by mod_proxy.
A possible solution would be, of course to be more careful with the rule
(splitting at the ;). A more general solution would be to add ; to the safe
T_OS_ESCAPE_PATH characters in gen_test_char.c. I'd prefer to do the latter
but dunno if there may be problems on non-unices.
What do you think?
nd
--
Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine
beiden Gefährten nicht zu zählen brauchte -- Karl May, Winnetou III
Im Westen was neues: http://pub.perlig.de/books.html#apache2
Re: cache trouble (Re: [vote] 2.1.9 as beta)
Nick Kew wrote: I'm not convinced by that either. In fact, I dislike the whole run it in a quick handler principle - it runs a supertanker through the KISS principle, and has consequently left us with a cache that never really worked. Even if we fix this, it's sure to have a high bugrate for the forseeable future precisely because it violates KISS. The principle behind running it in a quick handler in the original design was so that the cache could work as a 100% standards compliant HTTP/1.1 caching proxy, as described in section 13 of RFC2616. RFC2616 is well understood, and already nails down all security issues to do with proxy caching. Making the cache follow a widely accepted and known to work standard follows the KISS principle. Over time, the cache has slowly moved backwards from being as far forward on the frontend of the filter stack as possible, to further and further back into the webserver itself. In the process, the cache becomes less and less compliant with RFC2616, which has made it more difficult to understand and more complex to implement. The httpd cache is simply yet another cache in the chain of HTTP/1.1 caches that are typically present when a browser accepts a page from a website. The authentication issue is handled by RFC2616 already, and as long as httpd mod_cache conforms to the correct headers handling, and works like the other proxies in the chain, then authentication is not a problem. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Potential memory leak in /modules/cache/mod_mem_cache.c
Xuekun Hu wrote: So, same reason. Also in file mod_mem_cache.c around line 786, there is a malloc(mobj-m_len), and a few lines later, another malloc(obj-count) is performed. If the second malloc fails, I think also should add something like free(mobj-m); mobj-m = NULL; reasonable? No. Once a cache object is allocated, it will be cleaned up by cleanup_cache_object when the reference count drops to 0. To understand how this works, find this line of code. apr_pool_cleanup_register(r-pool, obj, decrement_refcount, apr_pool_cleanup_null); When r-pool is cleaned up, decrement_refcount is called. decrement_refcount will call cleanup_cache_onject when the refcount goes to 0. Bill
Re: authn, authz and access. oh my.
On 11/3/2005 at 10:38 pm, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: As if the old system wasn't hard enough to wrap one's head around. Just when I had it figured out enough to go and write mod_auth_userdir you guys go and change things on me. BTW, when did this change? I've been lurking on this list since July and have only recently heard about this. Was it a secret or did I miss it? The authentication module refactoring actually took place about two years ago. The problem is that it is new functionality that is not necessarily backward compatible so it had to wait for Apache 2.2. But it has been available for testing and evaluating for quite a while. Also...I was originally toying with the idea of folding auth[n|z|?] stuff into mod_dav_userdir, just to have it all taken care of in one place. Any thoughts on that idea? Feasible? Bad news? I actually did this with mod_authnz_ldap mainly because there was too much information and resources that would have had to be shared or reconstructed between the two modules. The upside is that unless you have a need to implement some special type of authorization, you can rip all of the authorization stage from your module and rely on the existing authz modules. Then all you really need to worry about is what your module needs to do for authentication (authn). The other good news is that there is plenty of example code. Brad
Re: cache trouble (Re: [vote] 2.1.9 as beta)
Graham Leggett wrote: The httpd cache is simply yet another cache in the chain of HTTP/1.1 caches that are typically present when a browser accepts a page from a website. The authentication issue is handled by RFC2616 already, and as long as httpd mod_cache conforms to the correct headers handling, and works like the other proxies in the chain, then authentication is not a problem. I agree with you about 90%. The problem is that there are a very few things that aren't accounted for in standard HTTP caching rules. One example is Varying access by client IP address. Another example is changing protocol behavior when communicating with the client. Reasonable proxy administrators may want to do these things. Joshua.
Re: Omission in the documentation
Bengt-Arne Fjellner [EMAIL PROTECTED] writes: The documentation for APR::Request ought to mention that atleast jar and params returns undef if there is no cookie/param done. -- Joe Schaefer
Re: cache trouble (Re: [vote] 2.1.9 as beta)
Joshua Slive wrote: I haven't looked carefully at the code, but I don't believe protocol-level things like the force-response-1.0 variable are stored in the cache. If it's a global setenvif variable (runs is post-read, before quick-handler), then these adjustments work, because force-response-1.0 and others are at the protocol level, mod_cache doesn't cache whether it was a 1.0 or 1.1 response. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: cache trouble (Re: [vote] 2.1.9 as beta)
Joshua Slive said: I agree with you about 90%. The problem is that there are a very few things that aren't accounted for in standard HTTP caching rules. One example is Varying access by client IP address. I can't see how you could have any meaningful caching at all if the content is varied by IP address, unless you had the IP address in a header and did some clever caching of variants. In this case you'd probably not use the cache at all for this part of the URL space. Another example is changing protocol behavior when communicating with the client. What protocol behaviour would change, can you give an example? Regards, Graham --
Re: cache trouble (Re: [vote] 2.1.9 as beta)
I almost tried to snip the comments below in my reply, and there was nothing I could clip out - thank you Graham for explaining so clearly the entire design principals of how and why mod_proxy does exactly what it does. It leaves us wondering; how can allow from/deny from n.n.n.n be mapped to RFC 2616 semantics, or at least, without running the many server hooks on later requests? The only way I can see, is that we should have any more explicit allow from/deny from leave a marker in the request record from that authorization phase, and mark it nocache if the request doesn't otherwise set the authentication required headers. Thoughts? Graham Leggett wrote: Nick Kew wrote: I'm not convinced by that either. In fact, I dislike the whole run it in a quick handler principle - it runs a supertanker through the KISS principle, and has consequently left us with a cache that never really worked. Even if we fix this, it's sure to have a high bugrate for the forseeable future precisely because it violates KISS. The principle behind running it in a quick handler in the original design was so that the cache could work as a 100% standards compliant HTTP/1.1 caching proxy, as described in section 13 of RFC2616. RFC2616 is well understood, and already nails down all security issues to do with proxy caching. Making the cache follow a widely accepted and known to work standard follows the KISS principle. Over time, the cache has slowly moved backwards from being as far forward on the frontend of the filter stack as possible, to further and further back into the webserver itself. In the process, the cache becomes less and less compliant with RFC2616, which has made it more difficult to understand and more complex to implement. The httpd cache is simply yet another cache in the chain of HTTP/1.1 caches that are typically present when a browser accepts a page from a website. The authentication issue is handled by RFC2616 already, and as long as httpd mod_cache conforms to the correct headers handling, and works like the other proxies in the chain, then authentication is not a problem. Regards, Graham --
Re: cache trouble (Re: [vote] 2.1.9 as beta)
Graham Leggett wrote: Joshua Slive said: I agree with you about 90%. The problem is that there are a very few things that aren't accounted for in standard HTTP caching rules. One example is Varying access by client IP address. I can't see how you could have any meaningful caching at all if the content is varied by IP address, unless you had the IP address in a header and did some clever caching of variants. In this case you'd probably not use the cache at all for this part of the URL space. This is the case we've been discussing where someone wishes to, for example, restrict a reverse proxy to a particular network. I agree that it can't be done with standard caching rules, which is the problem. I don't think it is a huge problem, but I'm sure there are people who wish to run a host-restricted proxy. Another example is changing protocol behavior when communicating with the client. What protocol behaviour would change, can you give an example? force-response-1.0, for example. Brian points out that this could still work if it was global. But you couldn't apply particular protocol adjustments to particular areas of the URL-space. This probably isn't a big problem. Joshua.
Re: cache trouble (Re: [vote] 2.1.9 as beta)
On 11/04/2005 08:20 PM, Joshua Slive wrote: Graham Leggett wrote: [..cut..] In this case you'd probably not use the cache at all for this part of the URL space. This is the case we've been discussing where someone wishes to, for example, restrict a reverse proxy to a particular network. I agree that it can't be done with standard caching rules, which is the problem. I don't think it is a huge problem, but I'm sure there are people who wish to run a host-restricted proxy. What about forward proxies that should only be usable from certain client IP's? I admit I haven't tested so far, but these should fail also. Regards Rüdiger
Re: mod_deflate Vary header
On 11/04/2005 07:36 AM, Florian Zumbiehl wrote: [..cut..] Maybe I'm pessimistic, but I think, omitting the Vary header for uncompressed ressources will lead to poisoned caches, which statistically nearly always will request the uncompressed variant and so actually *add* load to your server's bandwidth. Hu? Erm, could it be that you are thinking of load-reducing caches put directly in front of the web server? In that case, I wonder how the web server's bandwidth could be the bottleneck?! To put this straight: I was thinking about web servers behind V.90/ISDN/ADSL lines where _that_ line usually will be the bottleneck on any connections to the outside world and about caching proxies in that outside world ... Yes, but if you do compression because some of your clients have low bandwith connections (but are capable of receiving compressed pages) and access your server via a proxy then not sending the Vary header can poison the cache in a way you do not want. Because if the client which causes the proxy to cache the response is not capable to receive compressed pages will cause the proxy to cache *only* the uncompressed version of the page. Regards Rüdiger
Re: mod_deflate Vary header
This has been discussed many times before and no one seems to understand what the fundamental problem is. It is not with the servers at all, it is with the CLIENTS. What both of you are saying is true... whether you "Vary:" on "Content-encoding" and/or "User-agent" or not... there is a risk of getting the wrong content ( compressed versus uncompressed ) "stuck" in a downstream cache. It is less and less likely these days that the cache will receive a request from a client that CANNOT "decompress", but still possible. Handling requests from clients that cannot decompress have become ( at long last ) the "fringe" cases but are no less important than ever. Microsoft Internet Explorer ( all versions ) will REFUSE to cache anything locally if it shows up with any "Vary:" headers on it. Period. End of sentence. So you might think you are doing your downstream clients a favor by tacking on a "Vary:" header to the compressed data so it gets 'stored' somewhere close to them... but you would be wrong. If you don't put a "Vary:" header on it... MSIE will, in fact, cache the compressed response locally and life is good. The user won't even come back for it until it's expired on their own hard drive or they clear their browser cache. However... if you simply add a "Vary:" header to the same compressed response... MSIE now refuses to cache that response at all and now you create a "thundering herd" scenario whereby the page is never local to the user for any length of time and each "forward" or "back" button hit causes the client to go upstream for the page each and every time. Even if there is a cache nearby you would discover that the clients are nailing it each and every time for the same page just because it has a "Vary:" header on it. I believe Netscape has the same problem(s). I don't use Netscape anymore. Anyone know for sure if Netscape actually stores "variants" correctly in local browser cache? Yours... Kevin Kiley In a message dated 11/4/2005 4:55:02 PM Central Standard Time, [EMAIL PROTECTED] writes: On 11/04/2005 07:36 AM, Florian Zumbiehl wrote: [..cut..] Maybe I'm pessimistic, but I think, omitting the Vary header for uncompressed ressources will lead to "poisoned" caches, which statistically nearly always will request the uncompressed variant and so actually *add* load to your server's bandwidth. Hu? Erm, could it be that you are thinking of load-reducing caches put directly in front of the web server? In that case, I wonder how the web server's bandwidth could be the bottleneck?! To put this straight: I was thinking about web servers behind V.90/ISDN/ADSL lines where _that_ line usually will be the bottleneck on any connections to the outside world and about caching proxies in that outside world ... Yes, but if you do compression because some of your clients have low bandwith connections (but are capable of receiving compressed pages) and access your server via a proxy then not sending the Vary header can "poison" the cache in a way you do not want. Because if the client which causes the proxy to cache the response is not capable to receive compressed pages will cause the proxy to cache *only* the uncompressed version of the page. Regards Rüdiger
Re: Documentation TODOs for 2.2
On Oct 30, 2005, at 2:05 PM, Nick Kew wrote: I'm just looking at docs/2.1 and noting some existing pages that definitely need updating. No reference to pages that need writing, or to non- English versions of anything. I might tackle some of these myself, but no promises. *** = really important, ** = should do, * = would be nice I just upgraded www.apache.org to 2.1.9, and the main holdup was the authn/authz modules... I'd put three stars *** next to some documentation on upgrading a given 2.0 AAA configuration to its 2.2 equivalent. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Edge connection filter cannot be removed?
This is currently listed as a show stopper in the 2.2.x/STATUS file: The edge connection filter cannot be removed: http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2 jerenkrantz asks: Why should this block a release? stas replies: because it requires a rewrite of the filters stack implementation (you have suggested that) and once 2.2 is released you can't do that anymore. I believe that this is really a feature enhancement. It is not a regression from the 2.0.xx branch. I don't believe it should be a show stopper for 2.2.x. If there is support to change the edge connection filters, get it into trunk first. Once it is in trunk, we can have a better handle on back port it to any branches. What does everyone think? I would like to remove this as a show stopper in a week if there are no objections. Thanks, -Paul
