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-dev&m=105366252619530&w=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
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
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: 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: 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: 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)
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: [PATCH] Broken APR_CHECK_APR_DEFINE() macro in test for APR_HAVE_IPV6 and APR_HAS_RANDOM
On Wed, Nov 02, 2005 at 02:10:19PM +0100, Martin Kraemer wrote:
> On Wed, Nov 02, 2005 at 12:43:42PM +, Joe Orton wrote:
> > Converting all use of $() when adding to INCLUDES in configure to ${} so
> > the paths get expanded immediately would seem like the best fix unless
> > there's some reason why that won't work (I can't think of any).
>
> As I said, you need a 2nd eval. Unless you mean that $top_builddir
> should be expanded *everywhere* immediately. But IMO it is much
> nicer to preserve the special property for $top_builddir
> of being the "top_builddir" as long as possible.
Well, you can't move your builddir after running configure so I can't
see why expanding the variable early really makes much difference.
> > config_vars.sh might need updating to strip the expanded paths properly
> > during installation.
>
> Here too it helps to know '$top_builddir' (and not just have the
> expanded path)...
>From a quick hack this doesn't not too complicated, the rest of the
*/config*.m4 files need munging like this too for a complete solution.
Index: configure.in
===
--- configure.in(revision 330354)
+++ configure.in(working copy)
@@ -136,6 +136,12 @@
abs_srcdir=`(cd $srcdir && pwd)`
abs_builddir=`pwd`
+dnl Export exact copies of these for use in build/config_vars.sh
+ap_abs_srcdir="$abs_srcdir"
+ap_abs_builddir="$abs_builddir"
+AC_SUBST(ap_abs_srcdir)
+AC_SUBST(ap_abs_builddir)
+
AC_ARG_WITH(pcre,
APACHE_HELP_STRING(--with-pcre=PATH,Use external PCRE library))
@@ -166,7 +172,7 @@
[--prefix=$prefix --exec-prefix=$exec_prefix
--libdir=$libdir --includedir=$includedir --bindir=$bindir])
APR_ADDTO(AP_LIBS, [$abs_builddir/srclib/pcre/libpcre.la])
- APR_ADDTO(INCLUDES, [-I\$(top_builddir)/srclib/pcre])
+ APR_ADDTO(INCLUDES, [-I${abs_builddir}/srclib/pcre])
AP_BUILD_SRCLIB_DIRS="$AP_BUILD_SRCLIB_DIRS pcre"
AP_CLEAN_SRCLIB_DIRS="$AP_CLEAN_SRCLIB_DIRS pcre"
@@ -180,10 +186,10 @@
APR_ADDTO(INCLUDES, [-I.])
if test "$abs_builddir" != "$abs_srcdir"; then
- APR_ADDTO(INCLUDES, [-I\$(top_builddir)/include])
+ APR_ADDTO(INCLUDES, [-I${top_builddir}/include])
fi
-APR_ADDTO(INCLUDES, [-I\$(top_srcdir)/os/\$(OS_DIR)
-I\$(top_srcdir)/server/mpm/\$(MPM_SUBDIR_NAME) -I\$(top_srcdir)/modules/http
-I\$(top_srcdir)/modules/filters -I\$(top_srcdir)/modules/proxy
-I\$(top_srcdir)/include -I\$(top_srcdir)/modules/generators
-I\$(top_srcdir)/modules/mappers -I\$(top_srcdir)/modules/database])
+APR_ADDTO(INCLUDES, [-I${abs_srcdir}/os/${OS_DIR}
-I${abs_srcdir}/server/mpm/${MPM_SUBDIR_NAME} -I${abs_srcdir}/modules/http
-I${abs_srcdir}/modules/filters -I${abs_srcdir}/modules/proxy
-I${abs_srcdir}/include -I${abs_srcdir}/modules/generators
-I${abs_srcdir}/modules/mappers -I${abs_srcdir}/modules/database])
# apr/apr-util --includes may pick up system paths for dependent
# libraries, so ensure these are later in INCLUDES than local source
Index: build/config_vars.sh.in
===
--- build/config_vars.sh.in (revision 330354)
+++ build/config_vars.sh.in (working copy)
@@ -39,6 +39,9 @@
APR_INCLUDEDIR="`${APR_CONFIG} --includedir`"
APU_INCLUDEDIR="`${APU_CONFIG} --includedir`"
+abs_srcdir="@ap_abs_srcdir@"
+abs_builddir="@ap_abs_builddir@"
+
installbuilddir="@exp_installbuilddir@"
exec sed "
@@ -62,6 +65,7 @@
/^MPM_SUBDIR_NAME/d
/^EXTRA_INCLUDES/{
s, = , = -I\$(includedir) ,
+ s, -I${abs_srcdir}/[^ ]*,,g
s, -I\$(top_srcdir)/[^ ]*,,g
s, -I\$(top_builddir)/[^ ]*,,g
}
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)
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: 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)
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: cache trouble (Re: [vote] 2.1.9 as beta)
Justin Erenkrantz wrote: 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 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. Joshua.
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: 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: 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: 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=227435&view=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:
>
[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 w
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).
Re: Problem with mod_proxy and ProxyPassReverse
Eric B. wrote: # Production Server ProxyPassReverse / ProxyPass /ASPTest/ http://192.168.100.1/ # Development & Test Server ProxyPassReverse / 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: 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: 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: 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 > >
