Re: [NOTICE] Intend to TR 2.4.12 tomorrow (Thurs, Jan 22)
I expect to TR around 1pm eastern... all code and patches expected to be in 2.4.12 are currently committed. No further changes expected.
[PATCH 57100] SSLProtocol ALL is ignored for virtual hosts
Hi, It would be great if somebody finds time to review the proposed patch for bug 57100 (and maybe commit it to trunk). Any feedback would be greatly appreciated. - https://issues.apache.org/bugzilla/show_bug.cgi?id=57100 Regards, Michael
out-of-thread response to running the test suite on Windows
(sorry, no time now to keep trying to trick the mail gatekeeper into accepting my in-thread response) Here are my notes from 6-7 months ago... They don't seem complete??? Maybe apxs_win32 from svn has fixes to avoid needing the editing to ap*.bat/.pl suggested below. I also remember posting other patches/asking questions on some of the mod_perl lists related to other issues I had with the framework on Windows, but maybe it was more tied to the higher-level build/test framework I was using at the time. http://perl.apache.org/dist/win32-bin/apxs_win32.tar.gz From apxs directory: perl Configure.pl --with-apache2=%HOME%\PREFIXES\241 --with-apache-prog=httpd.exe Edit apr-1-config.bat/.pl and apu-1-config.bat/.pl and build\config_vars.mk to remove /machine:I386 Edit apxs.bat/.pl to remove local $[ = 0. From httpd-test directory: essentially perl Makefile.PL -apxs %HOME%\PREFIXES\241\bin\apxs.bat If you get this when running: [Tue Nov 12 16:57:15.170325 2013] [rewrite:error] [pid 3344:tid 384] (OS 87)The parameter is incorrect. : AH00654: mod_rewrite: could not start RewriteMap program C:/Users/Trawick/svn/httpd-test/t/htdocs/modules/rewrite/numbers.pl Remove mod_rewrite from httpd.conf and try perl Makefile.PL ... again We must skip mod_include tests since it currently crashes on Windows and then subsequent tests fail since on Windows the framework runs httpd as -DONE_PROCESS. failures to put in t\SKIP: t\modules\include.t t\apache\byterange2.t t\apache\acceptpathinfo.t t\apache\expr.t t\apache\mmn.t t\apache\pr37166.t t\apache\server_name_port.t t\modules\access.t t\modules\asis.t t\modules\authz_core.t t\modules\cgi.t t\protocol\nntp-like.t t\security\CVE-2004-0747.t t\security\CVE-2009-1195.t -- Born in Roswell... married an alien... http://emptyhammock.com/
[VOTE] Release Apache httpd 2.4.12 as GA
The pre-release test tarballs for Apache httpd 2.4.12 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.12 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. NOTE: The *-deps are only there for convenience. Thx!
Re: [PATCH 57100] SSLProtocol ALL is ignored for virtual hosts
On Thu, Jan 22, 2015 at 8:27 AM, Michael Kaufmann m...@michael-kaufmann.ch wrote: Hi, It would be great if somebody finds time to review the proposed patch for bug 57100 (and maybe commit it to trunk). Any feedback would be greatly appreciated. - https://issues.apache.org/bugzilla/show_bug.cgi?id=57100 Thanks, committed to trunk and proposed for 2.4.x. That was quick! Thank you very much for reviewing and committing :-) Michael
Re: Running the test suite on Windows
I think the first point of confusion stemmed from those bash CGI scripts you mentioned. I could have sworn I saw more shebangs with paths in /usr/bin/, but that might have come from my semi-odd setup. I'm ssh-ing into cygwin then running the test suite with Strawberry perl through a couple of batch scripts I setup; I probably mistakenly ran Makefile.pl using cygwin perl at some point. Just to clarify, the server is built using the visual studio compiler, not using MinGW or Cygwin gcc, which is why I'm not using cygwin perl. Thanks for the link to the modperl apxs; I think I saw references to it around the web, but all the links were dead. On Wed, Jan 21, 2015 at 1:02 PM, wr...@rowe-clan.net wrote: - Original Message - Subject: Running the test suite on Windows From: Edward Lu chaos...@gmail.com Date: 1/21/15 10:05 am To: dev@httpd.apache.org It appears that the test framework has a bunch of dependencies on unix, e.g. it runs scripts with #!/usr/bin/ Running it under cygwin would fix some of those issues, but unfortunately, running under cygwin perl generates unix-like paths in the conf files which a windows-built httpd can't deal with. I'm currently trying to find where it configures those paths so I can hack around the issue. There's also the problem of Windows not having apxs, so a bunch of tests are skipped, but I'm ignoring that one for now. Does anyone have experience/advice/considerations to give on the subject? I'm reasonably confused by your first statement and I'd need a bit of clarification to comment further. You can't mean forward-slashed paths, those are just fine, even by windows itself; just like passing -- before passing file names with leading dashes on unix, you do need to disambiguate the option flag for windows own commands by enclosing such paths in quotes. From a windows command shell prompt, you can observe this with the command dir c:/windows Not sure which other scripts you are describing; if specific tests use script to test a feature, e.g. a test to execute a bash shell cgi, then that would simply be not applicable to windows (usually). You could introduce further tests that do exercise all of the mechanisms in the win32 cgi functionality (use registry verb associations or a shebang). But if you are describing something else, it must be a more recent test; the entire suite was developed in perl. Compiling under cygwin (or a truly cygwin build with a faux-posix clib) may have some interesting implications. APR implements constructs in a very NT kernel centric way with object handles, so a posix-like cygwin build might become confused at one point or another. I wouldn't expect a mingw build to have such issues since that is a wrapper over the msvcr runtime. If you can track these down, it would be nice to work around the problem cases. Finally, there is an apxs that was never integrated into the httpd project, by our friend Randy Kobes, and Jeff along with the modperl folk finally moved it into subversion (sadly, not httpd's yet :) https://svn.apache.org/repos/asf/perl/apxs/trunk/ Configure and build it on top of an already installed win32 httpd.
Re: [PATCH 57100] SSLProtocol ALL is ignored for virtual hosts
On Thu, Jan 22, 2015 at 8:27 AM, Michael Kaufmann m...@michael-kaufmann.ch wrote: Hi, It would be great if somebody finds time to review the proposed patch for bug 57100 (and maybe commit it to trunk). Any feedback would be greatly appreciated. - https://issues.apache.org/bugzilla/show_bug.cgi?id=57100 Thanks, committed to trunk and proposed for 2.4.x.
Re: [Patch] Simplifying mod_alias
On 31 Dec 2014, at 5:56 PM, Eric Covener cove...@gmail.com wrote: For a URL of http://example.com/foo/bar/baz.html # this matches against baz.html only FilesMatch (.*\.html)$ Redirect http://other.example.com/$1 /FilesMatch You would not have any way to match or capture some part of /foo/bar/. You could use the entire URL in an expression, but I think it would be difficult to tease it apart, and even making it just conditional would require something like wrapping in if. I think there are some big gaps in string-valued expressions, even if you do try to write a sophisticated one (this has popped up for me in a handful of contexts and I have flailed around in the grammar to no avail) This limitation affects the whole of the expression API, which covers more and more directives, so if this is a real problem we should fix it. Would it make sense to add a modifier to FilesMatch to indicate we want to match against the full path instead of just the filename, for example: FilesMatch ~ ^/full/(path)/to/(file)$ Alternatively, what would the impact be of allowing LocationMatch inside htaccess? Regards, Graham —
Re: svn commit: r1653955 - /httpd/httpd/branches/2.4.x/STATUS
Makes sense. On Thu, Jan 22, 2015 at 10:28 PM, Jim Jagielski j...@jagunet.com wrote: I chose not to fold it in... the config stuff was low risk; the below was not great risk, but higher than acceptable for a quick TR. On Jan 22, 2015, at 3:29 PM, Yann Ylavic ylavic@gmail.com wrote: On Thu, Jan 22, 2015 at 6:25 PM, minf...@apache.org wrote: Author: minfrin Date: Thu Jan 22 17:25:13 2015 New Revision: 1653955 URL: http://svn.apache.org/r1653955 Log: Vote and promote. Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1653955r1=1653954r2=1653955view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Thu Jan 22 17:25:13 2015 @@ -118,6 +118,13 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK: 2.4.x patch: trunks works +1: rjung, ylavic, wrowe + * mod_ssl: Fix renegotiation failures redirected to an ErrorDocument. + (segfault flaw) PR 57334. + trunk patch: http://svn.apache.org/r1644498 + 2.4.x patch: trunk works (module CHANGES) + +1: ylavic, wrowe, minfrin + + It seems that this (last minute) one has not hit 2.4.12...
Re: svn commit: r1653955 - /httpd/httpd/branches/2.4.x/STATUS
I chose not to fold it in... the config stuff was low risk; the below was not great risk, but higher than acceptable for a quick TR. On Jan 22, 2015, at 3:29 PM, Yann Ylavic ylavic@gmail.com wrote: On Thu, Jan 22, 2015 at 6:25 PM, minf...@apache.org wrote: Author: minfrin Date: Thu Jan 22 17:25:13 2015 New Revision: 1653955 URL: http://svn.apache.org/r1653955 Log: Vote and promote. Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1653955r1=1653954r2=1653955view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Thu Jan 22 17:25:13 2015 @@ -118,6 +118,13 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK: 2.4.x patch: trunks works +1: rjung, ylavic, wrowe + * mod_ssl: Fix renegotiation failures redirected to an ErrorDocument. + (segfault flaw) PR 57334. + trunk patch: http://svn.apache.org/r1644498 + 2.4.x patch: trunk works (module CHANGES) + +1: ylavic, wrowe, minfrin + + It seems that this (last minute) one has not hit 2.4.12...
New to Apache
Hi everyone I'm new to open source development and Apache and I wanted to contribute to it. Can anyone get me started. PS - I've already had looked on the stuff on the website.
Re: New to Apache
Hi, if you don't have any idea yet on what you would like to work on, maybe a good start is to go thrue our bugzilla. Look at subjects you understand or that seem easy. If a patch is already proposed you can try and test it, then report any feedback. If no patch is available, you can propose one yourself. I can give you a list a easy looking subject I have spotted in bugzilla if you wish. Any proposal on memory reduction usage is also welcome. CJ tmaybe Le 23/01/2015 00:31, Paawan Mukker a écrit : Hi everyone I'm new to open source development and Apache and I wanted to contribute to it. Can anyone get me started. PS - I've already had looked on the stuff on the website.
Re: svn commit: r1635428 - in /httpd/httpd/trunk: include/http_core.h server/core.c server/request.c
On 01/22/2015 12:22 AM, William A. Rowe Jr. wrote:
On Mon, 19 Jan 2015 16:28:46 -0600
William A. Rowe Jr. wr...@rowe-clan.net wrote:
On Sun, 18 Jan 2015 23:00:10 -0500
Eric Covener cove...@gmail.com wrote:
On Thu, Oct 30, 2014 at 4:34 AM, jkal...@apache.org wrote:
+/* core_dir_config is Directory*, but the requested
file is
+ * not a directory, so although the regexp could
match,
+ * we skip it. */
+if (entry_core-d_is_directory
r-finfo.filetype != APR_DIR) {
+continue;
+}
+
if (ap_regexec(entry_core-r, r-filename, nmatch,
pmatch, 0)) { continue;
}
I think this is broken.
You are correct, I don't think it means what the author thought this
code means.
Indeed, it was nonsense. The fix begins with some code similar to
[attached] but there are a number of shortcuts in the code that would
need to be accounted for by expanding the dir_len at the appropriate
time. The patch is also insufficient in that the r-filename buffer
needs to be at least one extra byte to compensate for the 'maybe a
trailing slash, maybe not' on a final directory component in a file
name.
Hi,
you are both right, sorry for the patch. I will revert it from trunk (if
not already done by someone else). That part of httpd looks more
complicated that I thought previously.
Jan Kaluza
That said, I'm putting this out there to get folks thinking, I can't
spend much more time on it myself, today.
Cheers,
Bill
RE: [NOTICE] Intend to TR 2.4.12 tomorrow (Thurs, Jan 22)
Hi Jim, Is the SO_REUSPORT patch committed in this build? Thanks, Lucy -Original Message- From: Jim Jagielski [mailto:j...@jagunet.com] Sent: Thursday, January 22, 2015 3:43 AM To: dev@httpd.apache.org Subject: Re: [NOTICE] Intend to TR 2.4.12 tomorrow (Thurs, Jan 22) I expect to TR around 1pm eastern... all code and patches expected to be in 2.4.12 are currently committed. No further changes expected.
Re: svn commit: r1653941 - in /httpd/httpd/trunk: CHANGES docs/manual/expr.xml docs/manual/mod/mod_alias.xml modules/mappers/mod_alias.c
On 22 Jan 2015, at 7:54 PM, Mike Rumph mike.ru...@oracle.com wrote: It might be preferred to use unsigned int for bit fields as is used in mod_proxy.h. IIRC there have been past discussions on problems resulting from signed bit fields. Updated in r1653978. Regards, Graham —
RE: [NOTICE] Intend to TR 2.4.12 tomorrow (Thurs, Jan 22)
Hi Jim, Thanks for the update! A quick question on the review and testing procedure. Right now, Yann Ylavic already made available a 2.4 version of the patch. The link is included at http://svn.apache.org/r1651967 . Is this good enough or is there anything additional needed at this point? If there is no bug reported, when 2.4.13 time is approaching, the patch will automatically be on the commit list or is there anything else we need to make sure? Thanks, Yingqi -Original Message- From: Jim Jagielski [mailto:j...@jagunet.com] Sent: Thursday, January 22, 2015 9:37 AM To: dev@httpd.apache.org Subject: Re: [NOTICE] Intend to TR 2.4.12 tomorrow (Thurs, Jan 22) Since that was a very new patch, there was a risk in adding it to 2.4.11/12 since it would not have had enough time for adequate testing. It will be proposed for 2.4.13. On Jan 22, 2015, at 12:14 PM, Lu, Yingqi yingqi...@intel.com wrote: Hi Jim, Is the SO_REUSPORT patch committed in this build? Thanks, Lucy -Original Message- From: Jim Jagielski [mailto:j...@jagunet.com] Sent: Thursday, January 22, 2015 3:43 AM To: dev@httpd.apache.org Subject: Re: [NOTICE] Intend to TR 2.4.12 tomorrow (Thurs, Jan 22) I expect to TR around 1pm eastern... all code and patches expected to be in 2.4.12 are currently committed. No further changes expected.
Re: svn commit: r1653955 - /httpd/httpd/branches/2.4.x/STATUS
On Thu, Jan 22, 2015 at 6:25 PM, minf...@apache.org wrote: Author: minfrin Date: Thu Jan 22 17:25:13 2015 New Revision: 1653955 URL: http://svn.apache.org/r1653955 Log: Vote and promote. Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1653955r1=1653954r2=1653955view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Thu Jan 22 17:25:13 2015 @@ -118,6 +118,13 @@ PATCHES ACCEPTED TO BACKPORT FROM TRUNK: 2.4.x patch: trunks works +1: rjung, ylavic, wrowe + * mod_ssl: Fix renegotiation failures redirected to an ErrorDocument. + (segfault flaw) PR 57334. + trunk patch: http://svn.apache.org/r1644498 + 2.4.x patch: trunk works (module CHANGES) + +1: ylavic, wrowe, minfrin + + It seems that this (last minute) one has not hit 2.4.12...
Re: [PATCH 57100] SSLProtocol ALL is ignored for virtual hosts
On Thu, Jan 22, 2015 at 4:45 PM, Eric Covener cove...@gmail.com wrote:
On Thu, Jan 22, 2015 at 8:27 AM, Michael Kaufmann
m...@michael-kaufmann.ch wrote:
Hi,
It would be great if somebody finds time to review the proposed patch for
bug 57100 (and maybe commit it to trunk). Any feedback would be greatly
appreciated.
- https://issues.apache.org/bugzilla/show_bug.cgi?id=57100
Thanks, committed to trunk and proposed for 2.4.x.
I was about to propose a different patch which maybe is less intrusive
(does not require a new SSL_PROTOCOL_UNSET defined).
It simply initializes the base server's protocol with SSL_PROTOCOL_ALL
(as before) but the vhosts ones with SSL_PROTOCOL_NONE.
Then we can use cfgMerge(protocol, SSL_PROTOCOL_NONE) as proposed by Michael.
Something like (based on code before r1653906) :
Index: modules/ssl/ssl_engine_config.c
===
--- modules/ssl/ssl_engine_config.c(revision 1653011)
+++ modules/ssl/ssl_engine_config.c(working copy)
@@ -97,7 +97,7 @@ BOOL ssl_config_global_isfixed(SSLModConfigRec *mc
** _
*/
-static void modssl_ctx_init(modssl_ctx_t *mctx, apr_pool_t *p)
+static void modssl_ctx_init(modssl_ctx_t *mctx, apr_pool_t *p, int vh)
{
mctx-sc = NULL; /* set during module init */
@@ -110,7 +110,7 @@ BOOL ssl_config_global_isfixed(SSLModConfigRec *mc
mctx-ticket_key = NULL;
#endif
-mctx-protocol= SSL_PROTOCOL_ALL;
+mctx-protocol= vh ? SSL_PROTOCOL_NONE : SSL_PROTOCOL_ALL;
mctx-pphrase_dialog_type = SSL_PPTYPE_UNSET;
mctx-pphrase_dialog_path = NULL;
@@ -161,14 +161,13 @@ BOOL ssl_config_global_isfixed(SSLModConfigRec *mc
#endif
}
-static void modssl_ctx_init_proxy(SSLSrvConfigRec *sc,
- apr_pool_t *p)
+static void modssl_ctx_init_proxy(SSLSrvConfigRec *sc, apr_pool_t *p, int vh)
{
modssl_ctx_t *mctx;
mctx = sc-proxy = apr_palloc(p, sizeof(*sc-proxy));
-modssl_ctx_init(mctx, p);
+modssl_ctx_init(mctx, p, vh);
mctx-pkp = apr_palloc(p, sizeof(*mctx-pkp));
@@ -179,14 +178,13 @@ BOOL ssl_config_global_isfixed(SSLModConfigRec *mc
mctx-pkp-ca_certs = NULL;
}
-static void modssl_ctx_init_server(SSLSrvConfigRec *sc,
- apr_pool_t *p)
+static void modssl_ctx_init_server(SSLSrvConfigRec *sc, apr_pool_t *p, int vh)
{
modssl_ctx_t *mctx;
mctx = sc-server = apr_palloc(p, sizeof(*sc-server));
-modssl_ctx_init(mctx, p);
+modssl_ctx_init(mctx, p, vh);
mctx-pks = apr_pcalloc(p, sizeof(*mctx-pks));
@@ -198,7 +196,7 @@ BOOL ssl_config_global_isfixed(SSLModConfigRec *mc
#endif
}
-static SSLSrvConfigRec *ssl_config_server_new(apr_pool_t *p)
+static SSLSrvConfigRec *ssl_config_server_new(apr_pool_t *p, int vh)
{
SSLSrvConfigRec *sc = apr_palloc(p, sizeof(*sc));
@@ -224,9 +222,9 @@ BOOL ssl_config_global_isfixed(SSLModConfigRec *mc
#endif
sc-session_tickets= UNSET;
-modssl_ctx_init_proxy(sc, p);
+modssl_ctx_init_proxy(sc, p, vh);
-modssl_ctx_init_server(sc, p);
+modssl_ctx_init_server(sc, p, vh);
return sc;
}
@@ -236,7 +234,7 @@ BOOL ssl_config_global_isfixed(SSLModConfigRec *mc
*/
void *ssl_config_server_create(apr_pool_t *p, server_rec *s)
{
-SSLSrvConfigRec *sc = ssl_config_server_new(p);
+SSLSrvConfigRec *sc = ssl_config_server_new(p, s-is_virtual);
sc-mc = ssl_config_global_create(s);
@@ -254,7 +252,7 @@ static void modssl_ctx_cfg_merge(apr_pool_t *p,
modssl_ctx_t *add,
modssl_ctx_t *mrg)
{
-cfgMerge(protocol, SSL_PROTOCOL_ALL);
+cfgMerge(protocol, SSL_PROTOCOL_NONE);
cfgMerge(pphrase_dialog_type, SSL_PPTYPE_UNSET);
cfgMergeString(pphrase_dialog_path);
@@ -337,7 +335,7 @@ void *ssl_config_server_merge(apr_pool_t *p, void
{
SSLSrvConfigRec *base = (SSLSrvConfigRec *)basev;
SSLSrvConfigRec *add = (SSLSrvConfigRec *)addv;
-SSLSrvConfigRec *mrg = ssl_config_server_new(p);
+SSLSrvConfigRec *mrg = ssl_config_server_new(p, 1);
cfgMerge(mc, NULL);
cfgMerge(enabled, SSL_ENABLED_UNSET);
--
Re: [PATCH 57100] SSLProtocol ALL is ignored for virtual hosts
On Thu, Jan 22, 2015 at 12:25 PM, Yann Ylavic ylavic@gmail.com wrote: I was about to propose a different patch which maybe is less intrusive (does not require a new SSL_PROTOCOL_UNSET defined). It simply initializes the base server's protocol with SSL_PROTOCOL_ALL (as before) but the vhosts ones with SSL_PROTOCOL_NONE. Then we can use cfgMerge(protocol, SSL_PROTOCOL_NONE) as proposed by Michael. No preference here (little familiarity either -- the distribution of Apache I spend most of my time on doesn't use mod_ssl) so feel free to replace. -- Eric Covener cove...@gmail.com
Re: svn commit: r1653941 - in /httpd/httpd/trunk: CHANGES docs/manual/expr.xml docs/manual/mod/mod_alias.xml modules/mappers/mod_alias.c
On 1/22/2015 9:02 AM, minf...@apache.org wrote:
==
--- httpd/httpd/trunk/modules/mappers/mod_alias.c (original)
+++ httpd/httpd/trunk/modules/mappers/mod_alias.c Thu Jan 22 17:02:22 2015
@@ -34,6 +34,7 @@
#include http_config.h
#include http_request.h
#include http_log.h
+#include ap_expr.h
typedef struct {
@@ -50,11 +51,20 @@ typedef struct {
} alias_server_conf;
typedef struct {
+int alias_set:1;
+int redirect_set:1;
apr_array_header_t *redirects;
+const ap_expr_info_t *alias;
+char *handler;
+const ap_expr_info_t *redirect;
+int redirect_status;/* 301, 302, 303, 410, etc */
} alias_dir_conf;
It might be preferred to use unsigned int for bit fields as is used in
mod_proxy.h.
IIRC there have been past discussions on problems resulting from signed
bit fields.
