PythonEnablePdb option.
The documentation for the Python debugger support in mod_python states: Because pdb is an interactive tool, start httpd from the command line with the -DONE_PROCESS option when using this directive. As soon as your handler code is entered, you will see a Pdb prompt allowing you to step through the code and examine variables. If you enable PythonEnablePdb but try to use Apache in its normal mode, ie., not as a single foreground process, you will get an error: Mod_python error: PythonHandler mptest Traceback (most recent call last): File /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/mod_python/apache.py, line 301, in HandlerDispatch assert (type(result) == type(int())), \ AssertionError: Handler 'mptest' returned invalid return code. This occurs because the pdb module internally generates an error when it somehow realises that it isn't being run in interactive mode. Rather than this exception being propagated, it simply returns None which causes the above error. Even if running pdb in single process mode, if quit is entered into pdb as a command, you will get a similar error. With the thought of mod_python perhaps ignoring the PythonEnabledPdb option when not run in single process mode, is there a way using the apache.mpm_query() function or some other function of determining that Apache is running in single process mode? This will not solve the quit problem, for that rather than calling pdb.runcall(), mod_python perhaps could implement an alternate variant of the Bdb.runcall() which is ultimately called which raises an appropriate Apache error more appropriate in context of mod_python when the BdbQuit exception is raised. Anyone have any thoughts? Anyone use the pdb support? Graham
Re: PythonEnablePdb option.
On Thu, 3 Nov 2005, Graham Dumpleton wrote: With the thought of mod_python perhaps ignoring the PythonEnabledPdb option when not run in single process mode, is there a way using the apache.mpm_query() function or some other function of determining that Apache is running in single process mode? I wonder if simply examining sys.argv would work? Grisha
Re: PythonEnablePdb option.
Graham Dumpleton wrote .. Grisha wrote .. On Thu, 3 Nov 2005, Graham Dumpleton wrote: With the thought of mod_python perhaps ignoring the PythonEnabledPdb option when not run in single process mode, is there a way using the apache.mpm_query() function or some other function of determining that Apache is running in single process mode? I wonder if simply examining sys.argv would work? Can't be done this way as sys.argv doesn't even exist in mod_python. ... Also need to sort out how -DONE_PROCESS and -X options are different, as pdb support also works if -X option is used. This is probably dangerous though to use as you still potentially get child processes and thus fire off more than one request and they will fight over standard input. To determine if -DONE_PROCESS was used on the command line, noting that -X is equivalent to -DONE_PROCESS and -DNO_DETATCH, one can use in the Apache configuration file: IfDefine ONE_PROCESS PythonEnablePdb On /IfDefine As far as I can tell, the IfDefine directive uses the Apache C function: ap_exists_config_define() Ie., the defined symbol is the argument: ap_exists_config_define(ONE_PROCESS) Unless I am missing something, there is no equivalent to being able to do IfDefine from within Python code executing inside of mod_python. It sounds though that in this case with pdb that it might be a potentially useful feature. Thus, what do people think about a new function: apache.exists_config_define(arg) Graham
[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_12356739
]
Graham Dumpleton commented on MODPYTHON-77:
---
There are now so many different suggestions on this that it is all too
confusing.
In respect of latest suggested change to release_interpreter(), this code
wasn't based on latest code from 3.2 betas and therefore doesn't include fix
for where Python doesn't support threading at all. Ie., the base code on which
it should have been made was:
static void release_interpreter(void)
{
PyThreadState *tstate = PyThreadState_Get();
#ifdef WITH_THREAD
PyEval_ReleaseThread(tstate);
#else
PyThreadState_Swap(NULL);
#endif
PyThreadState_Delete(tstate);
}
Ie., new call to PyThreadState_Swap() not factored in.
I will refrain from posting what it perhaps should be so as not to make things
worse.
In terms of the comment smallest required change, I am currently taking this
to mean that the most minimal change is still to install first interpreter as
main_interpreter and then to change release_interpreter() as suggested in
previous post.
Before anyone else posts any code, let me independently work out some changes
from scratch and thus verify the fixes or not. :-(
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
}
cache trouble (Re: [vote] 2.1.9 as beta)
On Wednesday 02 November 2005 20:26, William A. Rowe, Jr. wrote: Colm MacCarthaigh wrote: I think the text Deny from all is a particularly dangerous thing to have not work as advertised! No matter how well documented :/ Nasty. Is it necessarily a showstopper? The question though, is where can Deny from all be expected to work? Certainly not in Directory /foo - the cached entity no longer lives there. I disagree. If it came from there originally, then that's where it lives. The principle we want here is that retrieving from cache should have the same rules from a client PoV as retrieving an original unless a sysop explicitly says otherwise. Breaking that principle shouldn't hit the sysop as a standard or default behaviour. Perhaps in Location /foo - but running the full handlers, dealing with all the regex'es all over again defeats the purpose of running a fast cache. 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 main purpose of caching is to relieve the pressure on a big, slow backend. In real life, most of that bigness and slowness is pretty much always going to live in a handler or a backend, so what we save by running quick_handler is inherently of secondary importance. And there are several things we can do about that if we make cache a normal handler: * provide quick versions of early hooks. For example, an authn that looks up cached headers and thus bypasses any potential trip to DBD or LDAP. Similarly we may be able to bypass rewriterules, content negotiation, or any trip to htaccess based on cache lookup matching; maybe your CachedLocation proposal. In a sense, that's modularising the quick handler concept! * Write a caching performance doc that discusses the issue, and makes clear the effect of anything complex in a hook that can't be bypassed. Certainly in VirtualHost www.cachedhost.example.com ... although authnz doesn't work correctly there in the first place ;-) I take it that just refers to standard per-dir-config behaviour? A directive that's not even syntactically valid outside a directory-context can be forgiven for not working there! And certainly globally, if I ran a large mass vhost, yet knew full well that a list of proxies would corrupt my content, I might Deny from 10.123.55.0/24 but again, authn/authz doesn't work globally. Making it do so is a feature-enhancement, not a bugfix. And we'd need to have a proposal for implementation without undue complexity to consider such an enhancement. We can discuss 'enabling' the map to storage for Location and running the authz stack, but we would have to ensure we bypass the filesystem dir/files entities. The deepest relevant level is Location . In the present architecture that makes some sense. But having chopped out the hooks, adding them back in piecemeal seems reminiscent of Heath Robinson. And maybe, have you considered a CachedLocation / CachedLocationMatch container for mod_cache? This would have the benefit that very long lists of directives would be ignored/not merged, in favor of a much shorter and very specific list that benefits the cache by keeping it fast, while giving the user the option to tweak the behavior of content, once cached. You mean as a tool for sysops to accept/decline serving from cache? That could potentially have merit, and would work best in a quick-translation hook to bypass any more complex/expensive rules. The danger is if it grows some nightmarishly confusing relationship to normal Location semantics: the existing Location vs Directory is bad enough for non-expert users! -- Nick Kew
mod_mbox: unviewable message
Hi, I just found a message which mod_mbox can't seem to render: http://mail-archives.apache.org/mod_mbox/apr-dev/200509.mbox/[EMAIL PROTECTED] can that be fixed? The View raw message link is useful anyway ;) joe
mod_deflate Vary header
Hi, While configuring and testing my new and shiny Apache 2, I noticed that mod_deflate sends a Vary: Content-Encoding header whenever a resource could potentially be compressed, no matter whether it actually is compressed in that particular response. That certainly should work, but in situations where the server's bandwidth is the bottleneck, wouldn't it be a good idea to omit that Vary: header when no compression actually takes place? After all, any user agent should be able to cope with uncompressed content - and when that is what is already behind the bottleneck, like in some local proxy cache, a Vary: Content-Encoding header on it would cause a request from a user agent supporting compression to cause a reload of the compressed version from the slow server rather than delivering the already locally-available uncompressed version. When the bottleneck is at the client's end, it's completely different, of course--which is why I'd consider a config option a good idea that would allow the sending of a Vary: Content-Encoding in case of uncompressed content to be disabled. Cya, Florian
Re: mod_deflate Vary header
* Florian Zumbiehl [EMAIL PROTECTED] wrote: While configuring and testing my new and shiny Apache 2, I noticed that mod_deflate sends a Vary: Content-Encoding header whenever a resource could potentially be compressed, no matter whether it actually is compressed in that particular response. That certainly should work, but in situations where the server's bandwidth is the bottleneck, wouldn't it be a good idea to omit that Vary: header when no compression actually takes place? After all, any user agent should be able to cope with uncompressed content - and when that is what is already behind the bottleneck, like in some local proxy cache, a Vary: Content-Encoding header on it would cause a request from a user agent supporting compression to cause a reload of the compressed version from the slow server rather than delivering the already locally-available uncompressed version. Yes, that is the point. The Vary header describes which header(s) was used to decide, which content actually would be delivered. That's what HTTP specifies. When the bottleneck is at the client's end, it's completely different, of course--which is why I'd consider a config option a good idea that would allow the sending of a Vary: Content-Encoding in case of uncompressed content to be disabled. For your scenario it would be more useful to adjust the local cache, I think. (e.g. always request compressed content, decompress it and deliver it to all the clients uncompressed). 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. nd
Re: SSL enabled - nokeepalive in MSIE for non-SSL connections
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.
Re: [vote] 2.1.9 as beta
On Wed, Nov 02, 2005 at 03:08:47PM -0500, Joshua Slive wrote: Colm MacCarthaigh wrote: I think the text Deny from all is a particularly dangerous thing to have not work as advertised! No matter how well documented :/ Sure, but in truth, apache configuration is really complex and deny from all doesn't always really mean what it says. ... All that to say, I'm fine with the document that mod_cache ignores mod_access solution to this problem. Agreed, and I don't see why this is a showstopper either if this has been the behaviour of mod_cache forever anyway. showstopper === regression joe
Re: [vote] 2.1.9 as beta
On Thu, Nov 03, 2005 at 03:27:43PM +, Joe Orton wrote: Agreed, and I don't see why this is a showstopper either if this has been the behaviour of mod_cache forever anyway. showstopper === regression I've taken this out of the show-stopper section, I'll just live with documentation as a fix for now, and maybe fill that out a bit more. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
mod_access vs mod_authz_host
Is there really a rationale for that name change? This module is *not* an authz module in the sense of anything from the used-to-be-auth modules are. * It lives on a different request processing hook. * Its semantics, and even HTTP failure code, are different. * it uses TCP information rather than HTTP information. * It has a clear but *distinct* relationship with the real authz, expressed in the Satisfy Any|All directive. Reverting the name to mod_access will make it immediately more accessible to users (a name they know), and reduce the scope for future confusion. How about it? -- Nick Kew
Re: mod_access vs mod_authz_host
But it does handle access control which kind of puts in the category of authz vs. anywhere else. Brad On 11/3/2005 at 9:26:57 am, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Is there really a rationale for that name change? This module is *not* an authz module in the sense of anything from the used-to-be-auth modules are. * It lives on a different request processing hook. * Its semantics, and even HTTP failure code, are different. * it uses TCP information rather than HTTP information. * It has a clear but *distinct* relationship with the real authz, expressed in the Satisfy Any|All directive. Reverting the name to mod_access will make it immediately more accessible to users (a name they know), and reduce the scope for future confusion. How about it?
just how bad an idea is it to specify the path to suexec binary in httpd.conf?
ErrorLog /etc/some-important-database LoadModule hidden_module /usr/local/viewcvs-0.9.3/pipeopen.py SuexecWrapper /www/abc.example.com/bin/suexec If random user can edit main conf file, things are pretty bad, at least when root starts Apache. Perhaps there are more current limitations on possible harm when non-root starts Apache. Any thoughts on avoiding hard-coded path to suexec?
Re: mod_mbox: unviewable message
Hi, * Joe Orton [EMAIL PROTECTED] [2005-11-03 11:26:14]: Hi, I just found a message which mod_mbox can't seem to render: http://mail-archives.apache.org/mod_mbox/apr-dev/200509.mbox/[EMAIL PROTECTED] can that be fixed? The View raw message link is useful anyway ;) This message is not a valid MIME message. The first part does not contains headers, so mod_mbox passes this part of the message. I don't know enough about MIME constructions to decide how should mod_mbox behave. Any ideas or comments ? - Sam -- Maxime Petazzoni (http://www.bulix.org) -- gone crazy, back soon. leave message. signature.asc Description: Digital signature
Re: mod_mbox: unviewable message
On Thursday 03 November 2005 16:41, Maxime Petazzoni wrote: This message is not a valid MIME message. The first part does not contains headers, so mod_mbox passes this part of the message. I don't know enough about MIME constructions to decide how should mod_mbox behave. Any ideas or comments ? Erm, treat (default) that first (real) part as having a text/plain content-type header? -- Nick Kew
Re: mod_access vs mod_authz_host
On Thursday 03 November 2005 16:37, Brad Nicholes wrote: But it does handle access control which kind of puts in the category of authz vs. anywhere else. So can mod_rewrite and others, but that doesn't make it mod_authz_url! Perhaps mod_load_average should be called mod_authz_busy ? In terms of its role, mod_access is not an authz module, for the reasons mentioned in my previous post. Unless you can suggest some much stronger reason it should be? -- Nick Kew
Omission in the documentation
The documentation for APR::Request ought to mention that atleast jar and params returns undef if there is no cookie/param -- Bengt-Arne Fjellner
Re: mod_access vs mod_authz_host
Nick Kew wrote: On Thursday 03 November 2005 16:37, Brad Nicholes wrote: But it does handle access control which kind of puts in the category of authz vs. anywhere else. So can mod_rewrite and others, but that doesn't make it mod_authz_url! Perhaps mod_load_average should be called mod_authz_busy ? In terms of its role, mod_access is not an authz module, for the reasons mentioned in my previous post. Unless you can suggest some much stronger reason it should be? what about mod_access_host? that would give us mod_access_*, mod_authn_*, and mod_authz_* modules corresponding to the different aaa hooks... --Geoff
Re: mod_access vs mod_authz_host
On Thursday 03 November 2005 16:50, Nick Kew wrote: On Thursday 03 November 2005 16:37, Brad Nicholes wrote: But it does handle access control which kind of puts in the category of authz vs. anywhere else. So can mod_rewrite and others, but that doesn't make it mod_authz_url! Perhaps mod_load_average should be called mod_authz_busy ? In terms of its role, mod_access is not an authz module, for the reasons mentioned in my previous post. Unless you can suggest some much stronger reason it should be? Just to elaborate on that, it's the name I'm not happy about. I'm perfectly happy with the /modules/aaa/ classification. -- Nick Kew
Re: mod_access vs mod_authz_host
On Thursday 03 November 2005 16:52, Geoffrey Young wrote: what about mod_access_host? that would give us mod_access_*, mod_authn_*, and mod_authz_* modules corresponding to the different aaa hooks... Sounds good to me. -- Nick Kew
Re: mod_mbox: unviewable message
Nick Kew wrote: On Thursday 03 November 2005 16:41, Maxime Petazzoni wrote: This message is not a valid MIME message. The first part does not contains headers, so mod_mbox passes this part of the message. I don't know enough about MIME constructions to decide how should mod_mbox behave. Any ideas or comments ? Erm, treat (default) that first (real) part as having a text/plain content-type header? +1, I think this is a reasonable behavior, if there isn't a content-type specified. -Paul
Re: SSL enabled - nokeepalive in MSIE for non-SSL connections
On Thursday 03 November 2005 09:37 am, 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. Same here. This was also causing some funky behavior for my web application when running over SSL with IE6 clients downloading files. Removing this fixed the problem. -- Anish Mistry [EMAIL PROTECTED] AM Productions http://am-productions.biz/ pgpLRnK3yFAqn.pgp Description: PGP signature
[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_12356706
]
Boyan Boyadjiev commented on MODPYTHON-77:
--
The smalest required change for a correct pythreadstate handling is the
following (which is the same as in mod_python.c.diff but without the GIL stuff):
static void release_interpreter(void)
{
PyThreadState *tstate = PyThreadState_Get();
#ifdef WITH_THREAD
PyThreadState_Clear(tstate);
/*
PyThreadState_DeleteCurrent will clear also the TLS,
which will allow re-using the current thread with another
Python interpreter !!!
*/
PyThreadState_DeleteCurrent();
#else /*WITH_THREAD*/
PyThreadState_Delete(tstate);
#endif /*WITH_THREAD*/
}
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 I see fewer leaks in
BoundsChecker :-).
--
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:
Re: cache trouble (Re: [vote] 2.1.9 as beta)
On 11/03/2005 11:01 AM, Nick Kew wrote: On Wednesday 02 November 2005 20:26, William A. Rowe, Jr. wrote: Colm MacCarthaigh wrote: [..cut..] Certainly not in Directory /foo - the cached entity no longer lives there. I disagree. If it came from there originally, then that's where it lives. The principle we want here is that retrieving from cache should have the same rules from a client PoV as retrieving an original unless a sysop explicitly says otherwise. Breaking that principle shouldn't hit the sysop as a standard or default behaviour. I agree with Nick on this as this creates the potential for confusion on user side. It also make the behaviour inconsistent for already cached data and data that gets cached the first time. From developer perspective I understand the performance penalties of doing so. 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 main purpose of caching is to relieve the pressure on a big, slow backend. In real life, most of that bigness and slowness is pretty much always going to live in a handler or a backend, so what we save by running quick_handler is inherently of secondary importance. And there are several things we can In the cases you describe here (and for what I use it personally) I agree, but for other cases, e.g. the one Colm uses it (storing cached data on faster disks, than the uncached data) I think running in handler is a pain. I think in principle, it would be fine to choose via a configuration directive where to run mod_cache as Paul's patch suggested. What is currently bothering me about this idea is that this is a nice thing for people with inside view, but it is not really transparent to users. So what this configuration option actually does from the users perspective must be expressed more clearly by doing this configuration. Maybe a good name for this directive can be enough. [..cut..] And maybe, have you considered a CachedLocation / CachedLocationMatch container for mod_cache? This would have the benefit that very long lists of directives would be ignored/not merged, in favor of a much shorter and very specific list that benefits the cache by keeping it fast, while giving the user the option to tweak the behavior of content, once cached. You mean as a tool for sysops to accept/decline serving from cache? That could potentially have merit, and would work best in a quick-translation hook to bypass any more complex/expensive rules. The danger is if it grows some nightmarishly confusing relationship to normal Location semantics: the existing Location vs Directory is bad enough for non-expert users! I also agree with this. While I understand the performance benefits from the developer perspective, I fear the confusion from the user and administrators perspective. Having a clear configuration is not only about having non-expert users getting it work but also to ease the job of expert administrators to understand what they configured a year or so after they did :-). Regards Rüdiger
Re: SSL enabled - nokeepalive in MSIE for non-SSL connections
On 11/3/05, Anish Mistry [EMAIL PROTECTED] wrote: On Thursday 03 November 2005 09:37 am, 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. Same here. This was also causing some funky behavior for my web application when running over SSL with IE6 clients downloading files. Removing this fixed the problem. Just wondering, what kind of funky behaviour?
Re: cache trouble (Re: [vote] 2.1.9 as beta)
--On November 3, 2005 8:44:02 PM +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: I also agree with this. While I understand the performance benefits from the developer perspective, I fear the confusion from the user and administrators perspective. Having a clear configuration is not only about having non-expert users getting it work but also to ease the job of expert administrators to understand what they configured a year or so after they did :-). In my performance analyses that I did when redoing mod_cache last year, a substantial part of the time in httpd was spent in all of the hooks prior to the handler. Things like BrowserMatch (which do regex's) are ridiculously expensive. So, moving the cache to a regular handler is not a minor performance penalty - it's a major one. And, probably to the point where there's *no* performance increase for even having a cache - unless you are combining it with a backend proxy. -- justin
Re: SSL enabled - nokeepalive in MSIE for non-SSL connections
On Thursday 03 November 2005 05:18 pm, Olaf van der Spek wrote: On 11/3/05, Anish Mistry [EMAIL PROTECTED] wrote: On Thursday 03 November 2005 09:37 am, 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. Same here. This was also causing some funky behavior for my web application when running over SSL with IE6 clients downloading files. Removing this fixed the problem. Just wondering, what kind of funky behaviour? I can't remember exactly, but it would try to start download and them IE would display and error box (The one with the red X) saying something that it cannot download the file. -- Anish Mistry [EMAIL PROTECTED] AM Productions http://am-productions.biz/ pgpgXCZAboHwG.pgp Description: PGP signature
Problem with mod_proxy and ProxyPassReverse
Hi, I'm struggling to get Apache to work properly as a Proxy to an internal server. I have two copies of the same application running on this internal server (both ASP applications running on IIS) that I need to access via different URLs. I have managed to configure on and got it working without problems, but it is the second one that is causing me the problem. Here is my config file VirtualHost *:80 ServerName www.domain.com DocumentRoot /var/www/html/www.domain.com # 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/ /VirtualHost The ASP application's default.aspx page has a button that redirects the user to intro.aspx ( Response.Redirect(intro.aspx) ) Now, accessing the server as www.domain.com/ASPTest/ works without problems. I see the application running on 192.168.100.1 properly. When I click the submit button on the default.aspx page, I get redirected to http://www.domain.com/ASPTest/intro.aspx. And so on. This applications works perfectly well. However, when I try to access http://www.domain.com/dev/ASPTest/, I run into problems. The default page loads fine and shows me default.aspx from port 8080. However, when I click the submit button on it, I get redirected to the same page as the non-development one - http://www.domain.com/ASPTest/intro.aspx. So from that point on, I am no longer working with the development code and back to the live production one. I tried to use ProxyPassReverse without the Location headers, but it doesn't work at all as soon as it receives the Response.Redirect() code. Can anyone point me in the right direction here? Why is my redirect from /dev/ASPTest/ getting redirected to /ASPTest/ instead? Thanks! Eric
Re: cache trouble (Re: [vote] 2.1.9 as beta)
Justin Erenkrantz wrote: --On November 3, 2005 8:44:02 PM +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: I also agree with this. While I understand the performance benefits from the developer perspective, I fear the confusion from the user and administrators perspective. Having a clear configuration is not only about having non-expert users getting it work but also to ease the job of expert administrators to understand what they configured a year or so after they did :-). In my performance analyses that I did when redoing mod_cache last year, a substantial part of the time in httpd was spent in all of the hooks prior to the handler. Things like BrowserMatch (which do regex's) are ridiculously expensive. So, moving the cache to a regular handler is not a minor performance penalty - it's a major one. And, probably to the point where there's *no* performance increase for even having a cache - unless you are combining it with a backend proxy. -- justin Or any other Dynamic source, like CGIs, PHP, etc. This can still be a major win, it just depends on your environment. This is why it should be configurable. To get the best out of caching, you need local knowledge. -Paul
Re: cache trouble (Re: [vote] 2.1.9 as beta)
Justin Erenkrantz wrote: In my performance analyses that I did when redoing mod_cache last year, a substantial part of the time in httpd was spent in all of the hooks prior to the handler. Things like BrowserMatch (which do regex's) are ridiculously expensive. Interesting to think, however, about what the purpose of all those regexes was (they are no longer in the 2.1 config). They were meant to fix protocol problems. Given that mod_cache doesn't run those hooks, it seems there is no way to work around client protocol problems. (Just sending Vary: User-Agent wouldn't fix the problem, because when the user agent matched a cached variant, the protocol adjustments still wouldn't be applied.) Important? I don't know. But if it is easy to make mod_cache configurable with regards to running all these hooks, I am sure that it would find uses. Joshua.
authn, authz and access. oh my.
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? Noobie question...what's the difference between authentication, authorization and access? At least in terms of the module interface. Or in other words, how much rewriting do I need to do? I'm looking at my config file for a DAV only server, and the only reason to include the old mod_access (now mod_authz_host?) was for the default deny all applied to the root directory. Do I really need that? Does the server really allow access to everything if not explicitly told otherwise? I'm going for a minimal config so I'd like to take out any unnecessary modules. I couldn't come up with a better name for mod_auth_userdir. Its supposed to authenticate against the database for mod_dav_userdir, but mod_auth_dav_userdir seemed too cumbersome. What should I call it now, given this new framework? 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?
Re: mod_deflate Vary header
Hi, Yes, that is the point. The Vary header describes which header(s) was used to decide, which content actually would be delivered. That's what HTTP specifies. To be exact, I'd say that HTTP specifies that it's about representation and not about content - which might even be the point here: The content stays the same, just the representation could change, but only in so far as the client certainly will be able to understand it. When the bottleneck is at the client's end, it's completely different, of course--which is why I'd consider a config option a good idea that would allow the sending of a Vary: Content-Encoding in case of uncompressed content to be disabled. For your scenario it would be more useful to adjust the local cache, I think. (e.g. always request compressed content, decompress it and deliver it to all the clients uncompressed). Sure - just that you usually don't have any admin access to the vast majority of the caches that might be accessing the web page you are publishing =:-) 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 ... Cya, Florian
Re: cache trouble (Re: [vote] 2.1.9 as beta)
On Thu, Nov 03, 2005 at 08:03:56PM -0500, Joshua Slive wrote: it seems there is no way to work around client protocol problems. (Just sending Vary: User-Agent wouldn't fix the problem, because when the user agent matched a cached variant, the protocol adjustments still wouldn't be applied.) Why wouldn't it? -- justin
