opensaml unmarshall Exception
Hi, Thank you for your suggestion and your concern ! That question last weekend have been resolved .But when I unmarshall DOM Document into SAML Object , there is an error : Caught an XMLSecurity exception while loading signature :OpenSSL : X509--Error transating Base64 DER encoding into OpenSSL X509 structure . I also google this question ,but have not get answers.I need your suggestion.Please! Thank you !
Re: opensaml unmarshall Exception
You should post your question to the OpenSAML mailing list, this isn't the place for it.
Re: [VOTE] Release httpd 2.2.16
On 22.07.2010 07:46, Ruediger Pluem wrote: On 07/22/2010 06:10 AM, William A. Rowe Jr. wrote: On 7/21/2010 10:09 PM, Rainer Jung wrote: On 22.07.2010 04:52, Paul Querna wrote: Ack-- I could re-tag with libtool 1.x, if we don't want to ship a modified apr-util. I always use an external expat it seems :( Thoughts? For the ASF release re-tag would be enough. There's a few people though, that already ran into the same problem with 2.2.15 (BZ49053). It's possible some distros might run buildconf before providing their source bundles, but it could also just have been those users themselves. The info given in the issue does not clarify this. Since the buildconf bug itself is not a regression and there are well known workarounds I would say re-tag and fix with 2.2.17. AIUI - this is a reroll, but the tag remains the same? If the source files in svn are nonvolatile, then going with libtool 1.x might be the ticket. +1 to reroll. The tag can stay the same. Don't know why Paul and me both used the wording re-tag when talking about a procedure that doesn't change the svn sources. So yes, I meant re-roll. Regards, Rainer
Re: [VOTE] Release httpd 2.2.16
On Thu, Jul 22, 2010 at 12:23 AM, Rainer Jung rainer.j...@kippdata.de wrote: On 22.07.2010 07:46, Ruediger Pluem wrote: On 07/22/2010 06:10 AM, William A. Rowe Jr. wrote: On 7/21/2010 10:09 PM, Rainer Jung wrote: On 22.07.2010 04:52, Paul Querna wrote: Ack-- I could re-tag with libtool 1.x, if we don't want to ship a modified apr-util. I always use an external expat it seems :( Thoughts? For the ASF release re-tag would be enough. There's a few people though, that already ran into the same problem with 2.2.15 (BZ49053). It's possible some distros might run buildconf before providing their source bundles, but it could also just have been those users themselves. The info given in the issue does not clarify this. Since the buildconf bug itself is not a regression and there are well known workarounds I would say re-tag and fix with 2.2.17. AIUI - this is a reroll, but the tag remains the same? If the source files in svn are nonvolatile, then going with libtool 1.x might be the ticket. +1 to reroll. The tag can stay the same. Don't know why Paul and me both used the wording re-tag when talking about a procedure that doesn't change the svn sources. So yes, I meant re-roll. re-rolled using libtool 1.x, tarballs in the same places. I'll bump up the end of the vote to end of day Saturday UTC if that helps more people try it out.
2.2.16 RC - pr17629.t failure on Linux
Relatively new test pr17629.t seems to be failing for me on Linux: # expected: begin-foobar-end # received: !!!ERROR!!! not ok 4 # Failed test 4 in t/apache/pr17629.t at line 47 Failed 1/4 subtests In the error log: [Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(48): [client 127.0.0.1] [mod_echo_post] going to echo 37 bytes [Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(63): [client 127.0.0.1] [mod_echo_post] ap_get_client_block got error [Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(67): [client 127.0.0.1] [mod_echo_post] done reading 0 bytes, 37 bytes remain ap_get_client_block doesn't provide any more detail on why it fails. Just me? Any suggestions on further debugging? Thanks, Dan
RE: 2.2.16 RC - pr17629.t failure on Linux
-Original Message- From: Dan Poirier [mailto:poir...@pobox.com] Sent: Donnerstag, 22. Juli 2010 16:21 To: dev@httpd.apache.org Subject: 2.2.16 RC - pr17629.t failure on Linux Relatively new test pr17629.t seems to be failing for me on Linux: # expected: begin-foobar-end # received: !!!ERROR!!! not ok 4 # Failed test 4 in t/apache/pr17629.t at line 47 Failed 1/4 subtests In the error log: [Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(48): [client 127.0.0.1] [mod_echo_post] going to echo 37 bytes [Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(63): [client 127.0.0.1] [mod_echo_post] ap_get_client_block got error [Thu Jul 22 09:52:45 2010] [debug] mod_echo_post.c(67): [client 127.0.0.1] [mod_echo_post] done reading 0 bytes, 37 bytes remain ap_get_client_block doesn't provide any more detail on why it fails. Just me? Any suggestions on further debugging? This is no regression but due to a backport that missed the boat for 2.2.16. See the STATUS file of 2.2.x and search for 17629. Regards Rüdiger
Re: 2.2.16 RC - pr17629.t failure on Linux
On 2010-07-22 at 10:32, Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com wrote: -Original Message- From: Dan Poirier [mailto:poir...@pobox.com] Sent: Donnerstag, 22. Juli 2010 16:21 To: dev@httpd.apache.org Subject: 2.2.16 RC - pr17629.t failure on Linux This is no regression but due to a backport that missed the boat for 2.2.16. See the STATUS file of 2.2.x and search for 17629. That would explain pr43939.t also, thanks. What about these? t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1) Failed test: 2 t/ssl/require.t (Wstat: 0 Tests: 8 Failed: 1) Failed test: 7 I don't see any SSL-related proposed backports in STATUS that could explain these. Dan
RE: 2.2.16 RC - pr17629.t failure on Linux
-Original Message- From: Dan Poirier [ Sent: Donnerstag, 22. Juli 2010 16:45 To: dev@httpd.apache.org Subject: Re: 2.2.16 RC - pr17629.t failure on Linux On 2010-07-22 at 10:32, Plüm, Rüdiger, VF-Group ruediger.pl...@vodafone.com wrote: -Original Message- From: Dan Poirier Sent: Donnerstag, 22. Juli 2010 16:21 To: dev@httpd.apache.org Subject: 2.2.16 RC - pr17629.t failure on Linux This is no regression but due to a backport that missed the boat for 2.2.16. See the STATUS file of 2.2.x and search for 17629. That would explain pr43939.t also, thanks. What about these? t/ssl/extlookup.t (Wstat: 0 Tests: 4 Failed: 1) Failed test: 2 t/ssl/require.t (Wstat: 0 Tests: 8 Failed: 1) Failed test: 7 I don't see any SSL-related proposed backports in STATUS that could explain these. I see these as well. They don't happen on trunk, but they happen with 2.2.15 as well, so it does not seem to be a regression. Nevertheless I do not understand why they happen at all. Regards Rüdiger
Re: [VOTE] Release httpd 2.2.16
On 22.07.2010 11:28, Paul Querna wrote: On Thu, Jul 22, 2010 at 12:23 AM, Rainer Jungrainer.j...@kippdata.de wrote: On 22.07.2010 07:46, Ruediger Pluem wrote: On 07/22/2010 06:10 AM, William A. Rowe Jr. wrote: On 7/21/2010 10:09 PM, Rainer Jung wrote: On 22.07.2010 04:52, Paul Querna wrote: Ack-- I could re-tag with libtool 1.x, if we don't want to ship a modified apr-util. I always use an external expat it seems :( Thoughts? For the ASF release re-tag would be enough. There's a few people though, that already ran into the same problem with 2.2.15 (BZ49053). It's possible some distros might run buildconf before providing their source bundles, but it could also just have been those users themselves. The info given in the issue does not clarify this. Since the buildconf bug itself is not a regression and there are well known workarounds I would say re-tag and fix with 2.2.17. AIUI - this is a reroll, but the tag remains the same? If the source files in svn are nonvolatile, then going with libtool 1.x might be the ticket. +1 to reroll. The tag can stay the same. Don't know why Paul and me both used the wording re-tag when talking about a procedure that doesn't change the svn sources. So yes, I meant re-roll. re-rolled using libtool 1.x, tarballs in the same places. EU mirror was updated quickly, but US mirror still shows the old files. New ones are dated 22-Jul-2010 09:23, httpd-2.2.16.tar.gz.md5 is: 7f33f2c8b213ad758c009ae46d2795ed *httpd-2.2.16.tar.gz Rainer
Re: [VOTE] Release httpd 2.2.16
On Wed, Jul 21, 2010 at 11:45 AM, Paul Querna p...@querna.org wrote: Test tarballs for Apache httpd 2.2.16 are available at: http://httpd.apache.org/dev/dist/ Your votes please; +/- 1 [+1] Release httpd-2.2.16 Vote closes at 02:00 UTC on Saturday July 24 2010. FTR, +1 Has been running on eris/harmonia just fine (svn.apache.org), seems happy and no new problems there. Thanks, Paul
Re: [VOTE] Release httpd 2.2.16
builds and runs on Slackware 13.0 and 13.1 -- Res What does Windows have that Linux doesn't? - One hell of a lot of bugs!
Re: [VOTE] Release httpd 2.2.16
Peanut Gallery vote: [+1] Release httpd-2.2.16 XP SP3, VC6 SDK 2003 R2 ... ~24 hours live w/ no problems seen XP SP3/Vista SP1, VC9 ... no problems noticed w/ light testing Server 2008 R2 (x64), SDK 7 ... no problems noticed w/ light testing Cheers Beers Gregg
Re: svn commit: r962989 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS docs/manual/mod/mod_dir.xml modules/mappers/mod_dir.c
On Sun, Jul 11, 2010 at 11:28 AM, n...@apache.org wrote:
Author: niq
Date: Sun Jul 11 05:58:13 2010
New Revision: 962989
URL: http://svn.apache.org/viewvc?rev=962989view=rev
Log:
Backport FallbackResource directive.
...
Modified: httpd/httpd/branches/2.2.x/modules/mappers/mod_dir.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/mappers/mod_dir.c?rev=962989r1=962988r2=962989view=diff
==
--- httpd/httpd/branches/2.2.x/modules/mappers/mod_dir.c (original)
+++ httpd/httpd/branches/2.2.x/modules/mappers/mod_dir.c Sun Jul 11 05:58:13
2010
...
@@ -243,6 +291,7 @@ static int fixup_dir(request_rec *r)
static void register_hooks(apr_pool_t *p)
{
ap_hook_fixups(fixup_dir,NULL,NULL,APR_HOOK_LAST);
+ ap_hook_fixups(fixup_dflt,NULL,NULL,APR_HOOK_LAST);
Does anybody recall an issue with modules that have multiples of the
same hook, creating a problem for other modules that want to go
specifically before or after the module?
(I think there is an issue with hook sorting, such that
successor/predecessor doesn't work in this case.)
Re: svn commit: r966869 - in /httpd/httpd/trunk: CHANGES include/http_core.h modules/filters/mod_filter.c modules/http/http_protocol.c server/core.c
On 07/22/2010 11:54 PM, n...@apache.org wrote:
Author: niq
Date: Thu Jul 22 21:54:39 2010
New Revision: 966869
URL: http://svn.apache.org/viewvc?rev=966869view=rev
Log:
Move AddOutputFilterByType implementation from core to mod_filter.
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/include/http_core.h
httpd/httpd/trunk/modules/filters/mod_filter.c
httpd/httpd/trunk/modules/http/http_protocol.c
httpd/httpd/trunk/server/core.c
Modified: httpd/httpd/trunk/include/http_core.h
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/http_core.h?rev=966869r1=966868r2=966869view=diff
==
--- httpd/httpd/trunk/include/http_core.h (original)
+++ httpd/httpd/trunk/include/http_core.h Thu Jul 22 21:54:39 2010
@@ -507,8 +507,6 @@ typedef struct {
const char *input_filters; /* forced with SetInputFilters */
int accept_path_info;/* forced with AcceptPathInfo */
-apr_hash_t *ct_output_filters; /* added with AddOutputFilterByType */
-
/*
* What attributes/data should be included in ETag generation?
*/
IMHO this requires a major bump.
Regards
Rüdiger
