Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Several 2rd-party modules (mod_fcgid, mod_fastcgi, mod_perl, mod_watch etc.) are given issues with 2.2.6 on Windows. Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, 06 September, 2007 22:20 Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review Ummm hrmm: A hurry backport is causing this and there is hardly tested in real live. Hopefully ASF comes with a patch soon. So you know what's causing this? Please point out the exact hurry backport so we can look there. And again, WHAT OTHER 3rd party modules are having problems?? Can you provide ANY FURTHER information other than cryptic its not working messages followed by ASF hates Windows users comments?? If we *knew* what the problems were, we'd try like heck to fix 'em. I know Bill looked hard and long, but had no luck, mostly because the amount of real concrete data was woefully lacking. On Sep 6, 2007, at 4:08 PM, Steffen wrote: Better we stop this thread. See the post at: http://www.apachelounge.com/forum/viewtopic.php? p=8691 , please do not reply to that post. Steffen - Original Message - From: Jim Jagielski [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, 06 September, 2007 21:47 Subject: Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review On Sep 6, 2007, at 3:25 PM, Steffen wrote: I'm assuming the we is you, right? It is not just me. We are a team and of course the users. Just as an example the other post from me here which is a report from an other webmaster. I report here test results from the Apache Windows Community from the Apache Lounge, mostly I receive them by mail. You said that we need to: advise the users not to use 2.2.6 because is not compatible with some mods which, afaik, is not the case. You reported issues with mod_fcgid, which may be true, but that hasn't been confirmed by anyone else, nor do I see reports to support the some mods statement as well. Unless, of course, the cryptic phrase An other report actually means The below is a report from someone else who is also seeing an issue instead of Oh, by the way, I also tried this personally and I see that mod_cgi is working OK for me.. With all this being the case, I can't see holding up a release nor can I see us (us being the ASF) making some blanket statement that Win32 users should not use 2.2.6 because it is not compatible with some mods... If we had some more supporting data for that, then maybe... Maybe we have to patch 2.2.6 to get it error-free. Well, there is the patches directory that, if we discover a bug, allows people to download the patch and rebuild. Of course, this all means tracking down and discovering the bug with some detailed debugging info rather than a it doesn't work :)
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
On Fri, 7 Sep 2007, Jorge Schrauwen wrote: Any more info how you got it to work with apxs? This works for me: C:\ C:\Apache2\bin\apxs -llibhttpd -D APACHE2 -p -IC:\Temp\mod_fcgid.2.1 -o mod_fcgid.so -c mod_fcgid.c fcgid_bridge.c fcgid_conf.c fcgid_pm_main.c arch\win32\fcgid_pm_win.c arch\win32\fcgid_proc_win.c arch\win32\fcgid_proctbl_win.c fcgid_protocol.c fcgid_spawn_ctl.c fcgid_bucket.c fcgid_filter.c (all on one line). -- best regards, Randy
SSL_VERSION_LIBRARY
Hi,
I installed the new httpd 2.2.6 on several machines. One of them runs
RedHat Enterprise Linux. Another is Solaris 2.9. When looking at the SSL
environment variables in a simple CGI, I notticed that on the Linux machine,
SSL_VERSION_LIBRARY is not set at all, and in the Solaris machine, it contains
several lines from the apache magic files.
SSL_VERSION_LIBRARY='---
--
# msword: file(1) magic for MS Word files
#
# Contributor claims:
# Reversed-engineered MS Word magic numbers
#
0 string \376\067\0\043 application/msword
0 string \333\245-\0\0\0 application/msword
# disable this one because it applies also to other
# Office/OLE documents for which msword is not correct. See PR#2608.
#0 string \320\317\021\340\241\261application/msword
#--
# printer: file(1) magic for printer-formatted files
#
# PostScript
0 string %! application/postscript
0 string \004%! application/postscript
# Acrobat
# (due to [EMAIL PROTECTED])
0 string %PDF- application/pdf
#--
# sc: file(1) magic for sc spreadsheet
#
38 string Spreadsheet application/x-sc
#--
# tex: file(1) magic for TeX files
#
# XXX - needs byte-endian stuff (big-endian and little-endian DVI?)
#
# From [EMAIL PROTECTED]
# Although we may know the offset of certain text fields in TeX DVI
# and font files, we can'\''t use them reliably because they are not
# zero terminated. [but we do anyway, christos]
0 string \367\002application/x-dvi
#0 string \367\203TeX generic font data
#0 string \367\131TeX packed font data
#0 string \367\312TeX virtual font data
#0 string This\ is\ TeX, TeX transcript text
#0 string This\ is\ METAFONT, METAFONT transcript text
# There is no way to detect TeX Font Metric (*.tfm) files without
# breaking them apart and reading the data. The following patterns
# match most *.tfm files generated by METAFONT or afm2tfm.
#2 string \000\021TeX font metric data
#2 string \000\022TeX font metric data
#34string \0 (%s)
# Texinfo and GNU Info, from Daniel Quinlan ([EMAIL PROTECTED])
#0 string \\input\ texinfoTexinfo source text
#0 string This\ is\ Info\ fileGNU Info text
# correct TeX magic for Linux (and maybe more)
# from Peter Tobias ([EMAIL PROTECTED])
#
0 leshort 0x02f7 application/x-dvi
# RTF - Rich Text Format
0 string {\\rtf application/rtf
#--
# animation: file(1) magic for animation/movie formats
#
# animation formats, originally from [EMAIL PROTECTED] (VaX#n8)
# MPEG file
0 string \000\000\001\263video/mpeg
#
#'
Do you have any idea what the problem might be? Both machine have the same
version of openssl, OpenSSL 0.9.8e 23 Feb 2007, and I have not found any
problems in the server otherwise.
Best,
Zvi.
--
Dr. Zvi Har'El mailto:[EMAIL PROTECTED]Department of Mathematics
tel:+972-54-4227607 Technion - Israel Institute of Technology
fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/Haifa 32000, ISRAEL
If you can't say somethin' nice, don't say nothin' at all. -- Thumper (1942)
Saturday, 26 Elul 5767, 8 September 2007, 9:30PM
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Yeah I figured it out a bit later and it indeed seems broke. Not sure whats wrong though I posted a debug log + user dump yesterday. On 9/8/07, Randy Kobes [EMAIL PROTECTED] wrote: On Fri, 7 Sep 2007, Jorge Schrauwen wrote: Any more info how you got it to work with apxs? This works for me: C:\ C:\Apache2\bin\apxs -llibhttpd -D APACHE2 -p -IC:\Temp\mod_fcgid.2.1 -o mod_fcgid.so -c mod_fcgid.c fcgid_bridge.c fcgid_conf.c fcgid_pm_main.c arch\win32\fcgid_pm_win.c arch\win32\fcgid_proc_win.c arch\win32\fcgid_proctbl_win.c fcgid_protocol.c fcgid_spawn_ctl.c fcgid_bucket.c fcgid_filter.c (all on one line). -- best regards, Randy -- ~Jorge
Re: [VOTE] Apache 2.2.6, 2.0.61 and 1.3.39 release candidate tarballs for review
Jorge Schrauwen wrote: Yeah I figured it out a bit later and it indeed seems broke. Not sure whats wrong though I posted a debug log + user dump yesterday. The debug log was unfortunately not very interesting, since it wasn't doing anything out of the ordinary at the time you interrupted the process. It's also not quite decipherable, you would have to build at minimum with /Oy- and ideally with /Zi for your compile flags, /debug (to create pdb's also for third party modules) to the linker. And to let Dr Watson dig through all the particularities of your system libraries, you can use WinDbg (a free download from MS) which has a very nice feature; you set up a local SymStore that can suck down the .pdb's of almost any Microsoft shipped .dll through an envvar that looks like; _NT_SYMBOL_PATH=srv*G:\symstore*http://msdl.microsoft.com/download/symbols ...like magic your crash dumps will include all backtraces through the win32 dll's and nt kernel. We do know something more about this flaw at this point; you'll find most of the details at http://issues.apache.org/bugzilla/show_bug.cgi?id=43329 Thankfully Tom's created this incident after (correctly) diagnosing what libfcgid does on Win32. It's trivial to solve, as Tom noted and I had further corrected in that incident, however it reverts to existing broken behavior with respect to APR. Apparently mod_fcgid has long assumed that invalid handles are it's clue that it should run. Foolish Win32-ish assumption; and the way it behaves when compiled under VC6 and VC8 seem to significantly disagree. This might be because VC8 tries to be more clever about repairing broken stdhandles for console applications. The bottom lines are these; the APR library exists to keep applications consistent - the basic behavior is that fd's 0, 1, 2 (Win32's STD HANDLE values) inherit the parent's pipes if not explicitly defined; some apps fail miserably when runing in a service context with a sub-par set of handles (e.g. cmd.exe for one, while on unix a program will open a file only to discover that fd occupies slot 0, 1, or 2 and becomes corrupted). So the question becomes; fix libfcgid? And/or; add an explicit and very platform independent feature to NOT inherit undefined handles from the parent to child process? If this feature were added, it would be possible to say NO_PIPE to all three handles, and on unix have fd's 0/1/2 all unused, on windows have them all contain INVALID_HANDLE_VALUE's. I'm sure there is a valid use case for this across platforms. Bill
Broken URI-unescaping in mod_proxy
PR 41798 and many related ones (eg 39746, 38980 - both of which I've
closed today) show a history of incorrect URL-unescaping in mod_proxy.
For PR41798, the attached patch looks like a fix: it just uses
r-unparsed_uri (escaped) instead of r-uri (unescaped) in
proxy_trans. I'm wondering if using unparsed_uri here risks
breaking something or has security implications we need to
consider, bearing in mind we already unescaped it and thus
verified it is well-formed.
Any thoughts? Whoever wrote the comment about the existing logic
breaking RFC1945 presumably didn't see it as being that simple.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Index: modules/proxy/mod_proxy.c
===
--- modules/proxy/mod_proxy.c (revision 573827)
+++ modules/proxy/mod_proxy.c (working copy)
@@ -523,6 +523,16 @@
const char *real;
ap_regmatch_t regm[AP_MAX_REG_MATCH];
char *found = NULL;
+const char *local_uri = r-unparsed_uri;
+/* r-uri has been unescaped at this point.
+ * Using it in a proxy breaks us for backends that expect
+ * escaped sequences - at least slashes. We can fix that
+ * using r-unparsed_uri. But does that itself break something
+ * else, or have security implications?
+ *
+ * We're too early to use per-dir config. Should this be
+ * a per-vhost config option, or universal, or ???
+ */
if (r-proxyreq) {
/* someone has already set up the proxy, it was possibly ourselves
@@ -531,11 +541,6 @@
return OK;
}
-/* XXX: since r-uri has been manipulated already we're not really
- * compliant with RFC1945 at this point. But this probably isn't
- * an issue because this is a hybrid proxy/origin server.
- */
-
for (i = 0; i conf-aliases-nelts; i++) {
if (dconf-interpolate_env == 1) {
fake = proxy_interpolate(r, ent[i].fake);
@@ -546,11 +551,11 @@
real = ent[i].real;
}
if (ent[i].regex) {
-if (!ap_regexec(ent[i].regex, r-uri, AP_MAX_REG_MATCH, regm, 0)) {
+if (!ap_regexec(ent[i].regex, local_uri, AP_MAX_REG_MATCH, regm, 0)) {
if ((real[0] == '!') (real[1] == '\0')) {
return DECLINED;
}
-found = ap_pregsub(r-pool, real, r-uri, AP_MAX_REG_MATCH,
+found = ap_pregsub(r-pool, real, local_uri, AP_MAX_REG_MATCH,
regm);
/* Note: The strcmp() below catches cases where there
* was no regex substitution. This is so cases like:
@@ -569,13 +574,13 @@
found = apr_pstrcat(r-pool, proxy:, found, NULL);
}
else {
-found = apr_pstrcat(r-pool, proxy:, real, r-uri,
+found = apr_pstrcat(r-pool, proxy:, real, local_uri,
NULL);
}
}
}
else {
-len = alias_match(r-uri, fake);
+len = alias_match(local_uri, fake);
if (len != 0) {
if ((real[0] == '!') (real[1] == '\0')) {
@@ -583,11 +588,12 @@
}
found = apr_pstrcat(r-pool, proxy:, real,
-r-uri + len, NULL);
+local_uri + len, NULL);
}
}
if (found) {
+ r-uri = local_uri; /* the backend should get it escaped */
r-filename = found;
r-handler = proxy-server;
r-proxyreq = PROXYREQ_REVERSE;
