DO NOT REPLY [Bug 35040] - test
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35040. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35040 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: FileSession segfaulting (Was: Re: _apache.emergency_unlock function?)
Hi dharana, I've been away for a few days, but should have some time to mess around with this today. dharana wrote: More info: It just happens with some classes. Some work and some won't, and I don't yet know why. Do you ever see segfaults if you only saving strings in your session, rather than objects? I have the feeling that I've seen mention of problems trying to pickle some objects. (Both DbmSession and FileSession create a pickle to store the data). I'm not sure if this was in the docs or on the mailing list. I'll dig around to see what I can find. Do you see the same segfault if you use DbmSession? If not then that would rule out a pickle problem. Some info: In my webapp when user logs in I save a User object (subclassing class Storable). And then I redirect. Works ok, no problem. Then, in another page I try to save a Website object (subclassing from both Storable and Website). It segfaults. Could it be something related to multiple inheritance? In my ignorance I thought so, but then when I try to save a Dbobj class just for testing purposes it also crashes. Dbobj inherits from object directly and has some methods defined as classmethod. My question is: how does mod_python knows where to look for a class while trying to retrieve it? Imagine I start a session in namespace a and then in namespace b I save a class instance which is only known to namespace b. What happens when namespace a tries to save the session or when it tries to load it again? How does it knows where to look for the class instance only known to namespace b? Interesting question. I'll need to refresh myself on the pickling mechanism. Maybe the problem lies there? Anyway I will save the object_id in the session instead of the class instance and I will load the object from it. I'm really sorry for the spam. My head starts spinning really fast when I see segfaults. Hey, this is not spam. :) And segfaults make my head spin too. Regards, Jim dharana wrote: This is driving me crazy. I'm finding it hard to make a simple testcase. I use a custom handler and somewhere in the code I do this: -- [snip] - from mypackage.mysubpackage.mysubsubpackage import db def run(req): req.sess['foo'] = object # req.sess['foo'] = db req.sess.save() return # I redirect the user another path with util.redirect and then the segfault # happens -- The moment I try to assign my own classes (ie: assigning db instead of object I must manually delete the pysid cookie to stop the segfaults. It seems as if mp corrupts or somehow leaves in an usable state the session after trying to save my objects. I tried with different objects and it happens with all of them. Does anyone knows how I can retrieve more info from the segfault? I don't like segfaults :( they don't tell why they don't like you. dharana wrote:
Re: FileSession segfaulting (Was: Re: _apache.emergency_unlock function?)
Hi Jim, Objects of types int, str, unicode, etc don't cause a segfault. Currently I'm storing just a string and an User object of mine. It segfaults when an undetermined ammount of time passes (it may be around 30 mins). It happens even if I'm continually browsing not just staring at the screen and it happens almost always. If I try to store a DynamicWebsite object it segfaults every time and at that moment, no need to wait some minutes. Background info: class User(Storable): # one single method which calls another custom function in another module of mine plus the inherited methods class DynamicWebsite(Website, Storable): # a more complex object. The base class Website assigns req to self.req. This child class modifies it in one of it's three methods. Perhaps has something to do? It also import custom modules from some of it's functions. class Storable(object): # just an interface to load/save from a db I will be a bit busy until saturday. I will try to make a testcase then, but it's not trivial. Perhaps it has to do with circular dependencies with the req object? Please look at my comment here: http://issues.apache.org/jira/browse/MODPYTHON-45 I can't see wether this has anything to do with the problem at hand but just in case. Jim Gallacher wrote: Hi dharana, I've been away for a few days, but should have some time to mess around with this today. -- dharana
Re: expat install libapreq2-2.0.5-dev
Marc Lambrichs wrote: Randy Kobes wrote: On Mon, 23 May 2005, Philip M. Gollucci wrote: Marc Lambrichs wrote: [ ... ] But wait, there's more. In file included from Apache2.xs:39 /home/mlambrichs/libapreq2-2.05-dev/glue/perl/xsbuilder/apreq_xs_postperl.h:21:34: modperl_unembed.h: No such file or directory Somehow I'm under the impression that the Makefile isn't fit for my system. That's strange - glue/perl/xsbuilder/apreq_xs_postperl.h of my copy is including modperl_perl_unembed.h, not modperl_unembed.h. Was this a cut-n-paste error, or is it really trying to include modperl_unembed.h? Also, do you have modperl_perl_unembed.h under your Apache2 include/ subdirectory? It should get installed there upon installing mod_perl-2. Probably a cut-n-paste error. Sorry about that. And yes...modperl_perl_unembed.h is under include directory. I think my freebsd system is a bit mixed up. I've changed the ports to a manual install in /usr/local/httpd_2.0.54. Made a manual install of libapreq2. Now I get: /libexec/ld-elf.so.1: /usr/local/lib/perl5/site_perl/5.8.5/mach/auto/APR/Request/Apache2/Apache2.so: Undefined symbol apreq_handle_apache2 simple case of RTFM. I didn't activate mod_apreq2. Sorry.
Re: APR::Request API for playing with cookies
Simon Perreault [EMAIL PROTECTED] writes:
I just want to get to the value of my cookie, which is a list of two
strings. I can get the frozen string of the cookie using:
my $cookie = $jar-{CookieID};
However this is not a blessed object, it's only a string.
How can I get my value() method?
$jar-cookie_class(My::Class);
my $cookie = $jar-{CookieID};
--
Joe Schaefer
Re: APR::Request API for playing with cookies
On Tuesday 24 May 2005 10:29, Joe Schaefer wrote:
$jar-cookie_class(My::Class);
my $cookie = $jar-{CookieID};
There is no default class? My first impression is that this is strange...
Also, I can't do this, right?
$req-jar-cookie_class('My::Class');
This seems to not have any effect.
Re: APR::Request API for playing with cookies
Simon Perreault [EMAIL PROTECTED] writes:
On Tuesday 24 May 2005 10:29, Joe Schaefer wrote:
$jar-cookie_class(My::Class);
my $cookie = $jar-{CookieID};
There is no default class? My first impression is
that this is strange...
It is for performance raisins, mainly,
but that's also how the C API works: if you
don't care about the objects stored in
our tables, you don't have to deal with them.
Also, I can't do this, right?
$req-jar-cookie_class('My::Class');
This seems to not have any effect.
Correct. It's a property of the $jar *variable*,
not the $req.
--
Joe Schaefer
Comments on bug #34834
Hi, What do you think of bug #34834 and the patch suggestion included there: http://issues.apache.org/bugzilla/show_bug.cgi?id=34834 I think the current inability to include an entry which ends in backslash '\' in httpd.conf is quite a clear handicap. The patch fixes this problem with very minor changes to the code. Or do you see some potential problems with it? Thanks, Timo
Re: Comments on bug #34834
[EMAIL PROTECTED] wrote: Hi, What do you think of bug #34834 and the patch suggestion included there: http://issues.apache.org/bugzilla/show_bug.cgi?id=34834 I think the current inability to include an entry which ends in backslash '\' in httpd.conf is quite a clear handicap. The patch fixes this problem with very minor changes to the code. Or do you see some potential problems with it? Nope. I committed it to trunk in revision 178209. Thanks for fixing this bug. -Paul
cache returned header in 304
Hello,
My configuration is :
- web server with Apache 1.3.33 (WEB)
- reverse-proxy with Apache 1.3.33 (tested with ProxyPass[Reverse] and
RewriteRule) (PROXY) (no DefaultType configured)
- reverse-cache-proxy with Apache 1.3.33 (CACHE)
When I do a request on a picture that return 304 (not modified) on WEB, it
returns
HTTP/1.0 304 Not Modified
Date: Tue, 24 May 2005 17:23:36 GMT
Server: Apache
ETag: 7af-33-4194f50a
When I do the same request on PROXY, it returns
HTTP/1.0 304 Not Modified
Date: Tue, 24 May 2005 17:23:30 GMT
Server: Apache
ETag: 7af-33-4194f50a
X-Cache: MISS from WEB
Connection: close
Content-Type: text/plain
And then the cache (CACHE) stores 'test/plain' as Content-Type, and remove the
good 'image/png' one.
There was an error like this with 'Content-Length': no content are returned
but false/default headers are store in the cache.
The patch, I send, remove all critical Content-... headers.
Benoit
--
Benoit DOLEZ, EXOSEC (http://www.exosec.fr/)
12 av des Pres - BL233, 78059 St Quentin en Yvelines cedex
Tel: +33 1 61 37 05 35 - Fax: +33 1 61 38 10 65
GSM: +33 6 71 01 69 32 - mailto:[EMAIL PROTECTED]
--- apache_1.3.33/src/modules/proxy/proxy_cache.c Tue Feb 17 22:52:22 2004
+++ apache_1.3.33-flx0.2/src/modules/proxy/proxy_cache.cTue May 24
19:20:17 2005
@@ -1531,6 +1531,14 @@
buff[17 * (7) - 1] = '\n';
buff[17 * (7)] = '\0';
}
+ if (ap_table_get(resp_hdrs, Content-Type))
+ ap_table_unset(resp_hdrs, Content-Type);
+ if (ap_table_get(resp_hdrs, Content-MD5))
+ ap_table_unset(resp_hdrs, Content-MD5);
+ if (ap_table_get(resp_hdrs, Content-Location))
+ ap_table_unset(resp_hdrs, Content-Location);
+ if (ap_table_get(resp_hdrs, Content-Encoding))
+ ap_table_unset(resp_hdrs, Content-Encoding);
}
if (!ap_proxy_table_replace(c-hdrs, resp_hdrs)) {
c-xcache = ap_pstrcat(r-pool, HIT from ,
ap_get_server_name(r), (with revalidation), NULL);
Re: svn commit: r164752 - /httpd/httpd/trunk/STATUS
I don't see this backport in 1.3, but I did provide a patch at one point. I'll update my patch and repost along with the magic number bumps that were talked about a month or so ago. -aaron, catching up on really old messages On Apr 25, 2005, at 11:45 PM, [EMAIL PROTECTED] wrote: Author: pquerna Date: Mon Apr 25 23:45:44 2005 New Revision: 164752 URL: http://svn.apache.org/viewcvs?rev=164752view=rev Log: AllowEncodedSlashes fix was backported in 2.0.52. Remove this STATUS file entry. Modified: httpd/httpd/trunk/STATUS Modified: httpd/httpd/trunk/STATUS URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/STATUS? rev=164752r1=164751r2=164752view=diff == --- httpd/httpd/trunk/STATUS (original) +++ httpd/httpd/trunk/STATUS Mon Apr 25 23:45:44 2005 @@ -358,9 +358,6 @@ Message-ID: Pine.LNX. [EMAIL PROTECTED] .cs.virginia.edu -* When sufficiently tested, the AllowEncodedSlashes/%2f patch - needs to be backported to 2.0 and 1.3. - * APXS either needs to be fixed completely for use when apr is out of tree, or it should drop query mode altogether, and we just grow an httpd-config or similar arrangement.
Re: svn commit: r153400 - in httpd/httpd/trunk: Makefile.in configure.in srclib/Makefile.in
[EMAIL PROTECTED] wrote:
Author: jorton
Date: Fri Feb 11 06:08:24 2005
New Revision: 153400
URL: http://svn.apache.org/viewcvs?view=revrev=153400
Log:
Support use of an external copy of the PCRE library:
* configure.in: Set abs_{builddir,srcdir} higher. Add --with-pcre
flag; build against external PCRE library if used.
This adds the path to the libpcre in srclib/pcre to the EXTRA_CFLAGS, eg:
-I/work/apache/httpd-listen-proto/srclib/pcre
This means the installed config_vars.mk references that build path, even
after it is installed. It would be nice if this could be added only for
the compile, and not exported.
-APR_SUBDIR_CONFIG(srclib/pcre,
+case $with_pcre in
+yes) AC_PATH_PROG(PCRE_CONFIG, pcre-config, false) ;;
+ /*) if test -d $with_pcre test -x $with_pcre/bin/pcre-config; then
+ PCRE_CONFIG=$with_pcre/bin/pcre-config
+ elif test -x $with_pcre; then
+ PCRE_CONFIG=$with_pcre
+ fi
+
+ if $PCRE_CONFIG --version /dev/null; then :; else
+ AC_MSG_ERROR([Did not find pcre-config script at $PCRE_CONFIG])
+ fi
+ ;;
+*) PCRE_CONFIG=false ;;
+esac
+
+if test $PCRE_CONFIG != false; then
+ AC_MSG_NOTICE([Using external PCRE library from $PCRE_CONFIG])
+ APR_ADDTO(CFLAGS, [`$PCRE_CONFIG --cflags`])
+ APR_ADDTO(LIBS, [`$PCRE_CONFIG --libs`])
+else
+ # Build the bundled PCRE
+ AC_MSG_NOTICE([Configuring PCRE regular expression library])
+
+ APR_SUBDIR_CONFIG(srclib/pcre,
[--prefix=$prefix --exec-prefix=$exec_prefix
--libdir=$libdir --includedir=$includedir --bindir=$bindir])
-echo $ac_n ${nl}Configuring Apache httpd ...${nl}
+ APR_ADDTO(AP_LIBS, [$abs_builddir/srclib/pcre/libpcre.la])
+ APR_ADDTO(CPPFLAGS, [-I$abs_builddir/srclib/pcre])
^^ offending bits here
-Paul
Re: svn commit: r153400 - in httpd/httpd/trunk: Makefile.in configure.in srclib/Makefile.in
On Tue, May 24, 2005 at 12:30:23PM -0700, Paul Querna wrote:
[EMAIL PROTECTED] wrote:
Author: jorton
Date: Fri Feb 11 06:08:24 2005
New Revision: 153400
URL: http://svn.apache.org/viewcvs?view=revrev=153400
Log:
Support use of an external copy of the PCRE library:
* configure.in: Set abs_{builddir,srcdir} higher. Add --with-pcre
flag; build against external PCRE library if used.
This adds the path to the libpcre in srclib/pcre to the EXTRA_CFLAGS, eg:
-I/work/apache/httpd-listen-proto/srclib/pcre
This means the installed config_vars.mk references that build path, even
after it is installed. It would be nice if this could be added only for
the compile, and not exported.
Yes, config_vars.mk is largely unsanitized in the installed tree, that's
a long-standing problem - EXTRA_INCLUDES is largely bogus too.
It could do with e.g. some clever sed script being run over it at
installation time; removing all the variables which aren't relevant to
the install tree and sanitizing the remainder.
joe
404 does not delete cached entries using mod_disk_cache
Felix Enning pointed me again to an interesting question regarding mod_cache / mod_disk_cache: The following situation was observed with Apache 2.0.54 (same applies to trunk): 1. A resource gets cached. 2. The original resource gets removed from the backend (e.g on a proxied webserver, on the local disk, wherever). 3. The client sents a request that forces the cache to revalidate this entry. 4. The 404 received from the backend is correctly passed back to the client by mod_cache. 5. The client sents a request that does NOT require the cache to revalidate this entry. 6. Cache delivers the old resource that had been cached before, instead of a 404. Is this behaviour intended and compliant with the RFC? The reason for this behaviour is that the remove_url function of mod_disk_cache is a dummy function (BTW: mod_mem_cache seems to really remove the cache entry in remove_url). If this behaviour is not intended I would have a look into this to create a patch. Regards Rüdiger
Re: 404 does not delete cached entries using mod_disk_cache
[EMAIL PROTECTED] wrote: Felix Enning pointed me again to an interesting question regarding mod_cache / mod_disk_cache: The following situation was observed with Apache 2.0.54 (same applies to trunk): 1. A resource gets cached. 2. The original resource gets removed from the backend (e.g on a proxied webserver, on the local disk, wherever). 3. The client sents a request that forces the cache to revalidate this entry. 4. The 404 received from the backend is correctly passed back to the client by mod_cache. 5. The client sents a request that does NOT require the cache to revalidate this entry. 6. Cache delivers the old resource that had been cached before, instead of a 404. Is this behaviour intended and compliant with the RFC? Not to my knowlegde. Given that mod_mem_cache and mod_disk_cache are doing different things is pretty much indicative that one of the two is wrong ;). The reason for this behaviour is that the remove_url function of mod_disk_cache is a dummy function (BTW: mod_mem_cache seems to really remove the cache entry in remove_url). If this behaviour is not intended I would have a look into this to create a patch. Please do! Sander
