Re: Apache calls initialize module twice
On Nov 13, 2003, at 2:43 PM, Jeff Trawick wrote: ap_mpm_query(), implemented by each MPM, would need some help from core to determine which pass of the pre/post-config hook it is, since that is out of the MPM's domain. It seems to me that the proposed patch (for modules) elegantly solves a problem that a significant percentage of modules have to worry about. I don't see why folding this into ap_mpm_query() is desirable when the fix already exists. I think you're saying the same thing...
Re: consider reopening 1.3
On Nov 16, 2003, at 4:12 AM, Glenn wrote: - lack of clear leadership and even basic direction scratch-an-itch development is fine and good, but not in total chaos Umm... this *is* the ASF. It's *developer* driven. The direction is defined by the developers. - cathedral development it appears that more than a few serious discussions have not happened on-list and instead happen on IRC or elsewhere (board rooms?) without apprising the list of what transpired. (Or have there been absolutely no recent design discussions?) I agree that in some cases, irc is replacing dev@, which is Not Good. Thank God we haven't started using stupid wikis. - patch management many patches posted to this list or the bug db languish in limbo. Very little happens until a core contributor decides to take over a patch (more often than not it is more than simply shepherding it) Little feedback; it often feels like nobody's home to answer the phone... - insufficient (developer) documentation sure, there's the source, but it takes a lot longer to wrap ones head around the Apache2 paradigms than it did for Apache 1.3 BUFFs and such. The barrier to entry is much higher; solid design documents would be infinitely helpful - many new contributors are frustrated and discouraged see all of the above The voluble Kevin Kiley said it well: Make it EASY to contribute... not a nightmare. The above are *not* 1.3 issues, per se, but httpd ones. *** We need to get back many of the disenfranchised Apache 1.3 developers Killing Apache 1.3 is not a good option. There is a strong business need in many places to stay with Apache 1.3. The better option is reopening the 1.3 tree. Release 1.4 and open a 1.5 dev tree, with the specific intent on having the 1.4 release eventually map _directly_ into a _seamless_ upgrade to Apache 2.x, with very easy and clear directions for using a reverse proxy for those legacy 1.3 third-pary modules.) While upgrading is not hard for developers, Apache is not a simple product. We need an even-better (tm) way to get users from There (Apache 1.3) to Here (Apache 2.x). Yes, more trees are extra work, but this community is rapidly deteriorating without them. As noted many times, 1.3 is actively maintained but not actively developed. To be honest, I've not seen that many people saying I *really* want to add this to 1.3!. If they had, chances are good that I'd +1 (not that what goes into 1.3 is my decision...). I'm curious how a 1.4 or whatever would make it easier for people to make that transition. What would 1.4 have or be for that to happen?
Re: consider reopening 1.3
On Nov 16, 2003, at 2:23 PM, Glenn wrote: I don't expect any of the current Apache developers would be interested in this. But plenty of people join the development community over time (see previous comments) and theoretically the opinions could change. Well, I am interested. And some others on this list are interested. What must we do to have the opportunity to scratch this itch? I suggested releasing 1.4 and opening 1.5 dev, along with better patch management, to which you also agree a better job need be done. I do not think that the _current_ Apache is and _will forever be_ the right tool for a web server. The size of the bug database and feature requests should be sufficient evidence to support this point. I also believe that there needs to be an even easier migration path from 1.3 to 2.x, despite how good it is already. So what will it take to convince the core developers to reopen 1.3? I'm less interested in opinions and more interested in getting something done. Why 1.4? What will 1.4 have that 1.3 does not? Or do you mean reopening 1.3 implies that it becomes 1.4? But as the RM for the last X 1.3 releases, I think (hope) that it's obvious that I think the 1.3 tree still has a lot of life and a lot of interest in it. The less-than-expected migration from 1.x to 2.x has not happened, and the reasons why are many and few. It's for that reason, and others, that I try to keep 1.3 going. I've never considered 1.3 closed so I see no need to re-open it. Maybe open it up more, that is, by allowing new features to be added, etc... I'm certainly ++1 about that. But I think confusing things with a 1.4/1.5 branch doesn't make sense, unless people can *actually* specify what would require a bump like that... So: +1 for officially allowing active development on 1.3 -1 for 1.4/1.5 just because
Re: consider reopening 1.3
On Nov 16, 2003, at 3:57 PM, Glenn wrote: Oh, how about my (effectively) 2-line patch which adds vhost to the error log, which I have posted to this list NO LESS THAN 6 TIMES and spaced out over the past 6 MONTHS in three different formats, using a global, expanding server_rec, and with #defines. Ok, that's true, but that *really* does not translate to a downpour of disenfranchised 1.3 developers begging for 1.3 to be re-opened :) I'm curious how a 1.4 or whatever would make it easier for people to make that transition. What would 1.4 have or be for that to happen? I have some different ideas. One is to distribute APR with 1.3 so that modules developers could incrementally move their modules to APR. Personal experience: I am writing a module for 1.3 and 2.0 and the only code reuse I manage to achieve is where I said 'screw both the Apache 1.3 and Apache 2.0 models' and decided that my module would only work on POSIX compliant systems, and wrote my own POSIX compliant socket routines. If I had access to APR in 1.3, I could maintaining my module with 2.0 paradigms and would be able to keep my module working with 1.3 with much less additional effort. Please note: I'm not in favor of implementing major changes to 1.3 that are not in-line with Apache 2.x, but am in favor of continuing bug fixes and making the eventual transition to 2.x easier. Interesting, but if the usage of APR was that deep within 1.3, then wouldn't backwards compatibility with 1.3 go out the window. I'm guessing this is your 1.4/1.5 branch. But that doesn't help the 1.3 people at all, since (if I'm understanding you correctly) all this does is create another Apache version... I may be misunderstanding you... or do you mean just have Apache 1.3 APR aware and not for 1.3 to *use* it per se, but allow for modules to call APR... That would be useful, but anything deeper than that would scare people I think... APR is just as new as Apache 2.0.
Re: consider reopening 1.3
Glenn wrote: On Sun, Nov 16, 2003 at 03:46:26PM -0500, Jim Jagielski wrote: Why 1.4? What will 1.4 have that 1.3 does not? Or do you mean reopening 1.3 implies that it becomes 1.4? Only semantics. .4 is even, so stable; .5 is development and less stable Personally, I've never liked that methodology Unless *really* controlled, I think it almost restricts development, since the 1.5 tree kind of gets super developed and only occasionally are safe things brought down to 1.4. Other development teams do this much better than we do, IMO. With our development scenario, and they way we are structured (no benevolent dictator), having one tree, which is developed and polished, seems almost healthier. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: consider reopening 1.3
Peter J. Cranstone wrote: What would 1.4 have or be for that to happen? You have 12 million users - shouldn't be hard to simply ask them what they would like to see. Postal fees will be hell... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: consider reopening 1.3
[EMAIL PROTECTED] wrote: Geez... it's nice to discover everybody hasn't just dropped dead! I see a lot of healthy 'things to do' coming out of this thread that could inject a lot of life back into the development... which is what the various threads the past few days have all been about. Action items?... Facts to face?... Still waiting to see what, exactly, people want to see in 1.3 that isn't there... So far, we've had a small handful of suggestions. It will be curious to see how many of those are handled by 2.0... But recall that it is the truth of things that everything has a time to end. I'm not saying that it is the time for 1.3 to be put to bed (and I'm not saying that it's not) but it will be one day. It happened with Apache 1.2. It happened with PHP3. It'll happen soon with PHP4. It happened with RH7. It happened with bind4 and bind8 and sendmail8.9, etc... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Antw: RE: consider reopening 1.3
Glenn wrote: On Mon, Nov 17, 2003 at 01:31:55PM -0500, Bill Stoddard wrote: Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit support) with all the Windows specific code stripped out and source compatability (to the extent possible) with Apache 1.3 modules would probably see rapid uptake. I can't say that thrills me but it's probably true... +1 Again, unless there is 100% binary compatibility, which I do NOT see with 1.4, then *what* is the driver for 1.4 over 2.x?? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Antw: RE: consider reopening 1.3
On Nov 17, 2003, at 1:31 PM, Bill Stoddard wrote: Colm MacCarthaigh wrote: On Mon, Nov 17, 2003 at 11:01:46AM -0700, Peter J. Cranstone wrote: Oh yes - forgot about v6... that's a must have for Apache. Is it available for 1.x? If not that would be the first feature to add. The KAME project has IPv6 patches for 1.3.* at ftp://ftp.kame.net/pub/kame/misc/ they work on KAME (ie *BSD) stacks but have issues on platforms without INET6_V6ONLY support (but just about work). linux.or.jp used to maintain an alternative patch with v6 support, but that's since gone. The patches are all truly horrendous. APR has a much better model for all of this. Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit support) with all the Windows specific code stripped out and source compatability (to the extent possible) with Apache 1.3 modules would probably see rapid uptake. I can't say that thrills me but it's probably true... Once we break binary compatibility, and with the above definition of 1.4 I think that's a certainty, then I don't see the big reason for a 1.4 over 2.0. There's a big diff, IMO, between opening up development on 1.3 and trying to make 1.3 a 2.0-lite.
Re: Antw: RE: consider reopening 1.3
On Nov 17, 2003, at 2:22 PM, Bill Stoddard wrote: In this economic environment (and perhaps this will turn out to be generally true from now on), companies are not making investments in IT unless they can get a proven and almost immediate return on that investment. Making the jump to Apache 2.0 -can- be a big investment (depending on how many custom/third party modules you use) Most people with those big investments are using at least *some* 3rd party modules. Having a 1.4 that is not binary compatible with 1.3 means that those 3rd party modules will need to be (at least) re-compiled for 1.4. So they will need to worry about 1.3, 1.4 and 2.0 (and potentially 2.2)... That's an *awful* lot to have people keep track of. I don't see companies out there wanting to do that... they will maintain their 1.3 modules for awhile, and their 2.x ones, because it *is* the next gen, but I think they would avoid 1.4 almost totally. Having 1.4 not be binary compatible with 1.3 severely limits its usefulness to those exact people that it's supposed to be helping.
Re: Antw: RE: consider reopening 1.3
On Nov 17, 2003, at 3:17 PM, Rasmus Lerdorf wrote: As someone working in a company like that, I can tell you definitively that this is not true. At least not here at the biggest web company in the world. -Rasmus Well, I can certainly say that with respect to many, many of the clients I've worked with, it most certainly *is* the case. Not having a WebLogic or WebSphere DSO, for example, puts 'em in a world of hurt. Big time. Look at the impact of not having 2.0 modules severely limited the acceptance of 2.0. Not having 1.4 modules will most certainly do the same*. If 1.4 == 1.3, binary-wise, then it's a non-issue; if not, it's a *major* issue. * Yes, part of the delay was due to porting, which may not be one with 1.4. But we are *still* talking about distribution, support, etc.. of a load of modules.
Re: 2.0.48 build on MacOS X 10.3 ?
Henri Gomez wrote:
/Users/hgo/httpd-2.0.48/srclib/pcre/libpcre.la
/Users/hgo/httpd-2.0.48/srclib/apr-util/libaprutil-0.la
/Users/hgo/httpd-2.0.48/srclib/apr-util/xml/expat/lib/libexpat.la
-liconv /Users/hgo/httpd-2.0.48/srclib/apr/libapr-0.la -lresolv
ld: warning multiple definitions of symbol _regcomp
/Users/hgo/httpd-2.0.48/srclib/pcre/.libs/libpcre.al(pcreposix.lo)
definition of _regcomp in section (__TEXT,__text)
/usr/lib/libSystem.dylib(regcomp.So) definition of _regcomp
ld: warning multiple definitions of symbol _regexec
/Users/hgo/httpd-2.0.48/srclib/pcre/.libs/libpcre.al(pcreposix.lo)
definition of _regexec in section (__TEXT,__text)
/usr/lib/libSystem.dylib(regexec.So) definition of _regexec
ld: warning multiple definitions of symbol _regfree
/Users/hgo/httpd-2.0.48/srclib/pcre/.libs/libpcre.al(pcreposix.lo)
definition of _regfree in section (__TEXT,__text)
/usr/lib/libSystem.dylib(regfree.So) definition of _regfree
These are (should be) non-fatal...
What gcc are you using ('gcc_select')?
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
A society that will trade a little liberty for a little order
will lose both and deserve neither - T.Jefferson
Re: 2.0.48 build on MacOS X 10.3 ?
Henri Gomez wrote:
These are (should be) non-fatal...
What gcc are you using ('gcc_select')?
stock gcc 3.3 which came with devtools
Did you confirm that 'httpd' isn't, in fact, created?
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
A society that will trade a little liberty for a little order
will lose both and deserve neither - T.Jefferson
[PATCH] 1.3: Add %X as alias for %c in LogFormat
' -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [PATCH] 1.3: Add %X as alias for %c in LogFormat
Jeff Trawick wrote: You may be on shaky ground there, Jim. At the hackathon, I suggested an interesting feature for 1.3 to one of those disenfranchised 1.3 developers* and was asked Why do you want to mess with 1.3? :) From our discussion, he clearly was ready for 1.3 to fade away as soon as possible. With any luck, he won't show up on-list and veto your patch. :) Isn't it nicer to separate style patches from functional patches? Yep, but I felt lazy today :) Plus, I wanted the full patch out there ;) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [PATCH] 1.3: Add %X as alias for %c in LogFormat
William A. Rowe, Jr. wrote: +1 for 1.3 - we made this change already for 2.0 when we encountered the problem (as we ship mod_ssl in 2.0, but not in 1.3). I found it interesting that you retained %c - I presume this means that %c continues to work until mod_ssl replaces it's meaning? Yes... It was my intent to keep existing configs still valid. Adding %X enabled that. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: UseCanonicalName Off *surprise*
1.3.29-dev actually changes the determination of the port value
with UCN off in effect.
The big question is if the client does NOT send a Host
header, and UCN is Off, should the port be the port
number used in the connection socket OR should we use
whatever Port is set to... The current implementation,
which I think is correct, is to use the physical port
number... The intent of UCN Off is to say, basically,
trust whatever the client sends you, as far as
hostname and port number... and with that in mind,
I think we should trust what port the client is talking
to in absence of Host (since that is closer to the
goal of Apache's concept of host:port not being the
final or high priority authority).
Also note that what 2.0 and what 2.1 does as far as
ap_get_server_port() with a non-existent Host header
are different... 1.3.29-dev follows the 2.1 logic.
On Dec 19, 2003, at 11:04 AM, William A. Rowe, Jr. wrote:
UseCanonicalName On
-or-
UseCanonicalName Off, but the Host: header was missing (e.g. HTTP/1.0)
In 1.3 - the host's {ServerName}:{Port} is returned.
In 2.0 - the host {Servername} is returned (must include port
suffix).
there were no surprises there.
UseCanonicalName Off, Host: header provided (HTTP/1.1)
The host name header *excluding the host header port suffix * of the
request
is concatenated to httpd 1.3's Port directive setting or the real
port number
in httpd 2.0.
Now this might appear to be a moot issue, but if a proxy that doesn't
mangling
headers bounces requests from port 80 to another server's port 8080
attempting
to impersonate the front end proxy, everything should work, in theory,
with
UseCanonicalName Off. As it turns out, UseCanonicalName must be turned
on to avoid the port :8080 suffix from being appended to the redirects.
Host headers (from my usual clients) do appear in the form
Host: localhost:8080
when the request http://localhost:8080/ is sent. UseCanonicalName Off
docs
state outright that we use the Host: header provided by the client.
The example
above shows that we do not. But if we correct the behavior, instead
of the docs,
then perhaps users will commonly end up with broken configs.
So I'm wondering what the consensus is - fix the docs, or the behavior?
Bill
Re: UseCanonicalName Off *surprise*
On Dec 19, 2003, at 1:35 PM, William A. Rowe, Jr. wrote: Let me be clear (on the 1.3 side)... one expects that given; UseCanonicalName Off Listen 8080 Port 80 an inbound request with a Host header of foo:80 would respond with the redirection http://foo:80/ It does not. The Listen port again applies until you turn UseCanonicalName On. That is not the case with 1.3.29-dev. We now honor the port # as sent by the client, no matter what Port says. If the client doesn't send the port # in the Host header, we grab the port number via the actual socket.
Re: UseCanonicalName Off *surprise*
Brian Akins wrote: We had something similar. What we did that works is: UseCanonicalName On Listen 80 Listen 8080 ServerName www.domain.com:80 So redirects, no matter what port they came in one, get redirected to port 80. This was our desired effect. Under 1.3?? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
[PATCH] Bugz 24483 for 1.3
Patch to close out Bugz 24483 for 1.3.29... basically
a backport of the 2.0 patch in the PR.
Index: src/modules/standard/mod_usertrack.c
===
RCS file: /home/cvs/apache-1.3/src/modules/standard/mod_usertrack.c,v
retrieving revision 1.58
diff -u -r1.58 mod_usertrack.c
--- src/modules/standard/mod_usertrack.c1 Jan 2004 13:32:56 - 1.58
+++ src/modules/standard/mod_usertrack.c12 Jan 2004 14:13:50 -
@@ -286,10 +286,29 @@
return;
}
-/* dcfg-regexp is ^cookie_name=([^;]+)|;[ \t]+cookie_name=([^;]+),
- * which has three subexpressions, $0..$2 */
+/*
+ * dcfg-regexp is ^cookie_name=([^;]+)|;[ \t]+cookie_name=([^;]+),
+ * which has three subexpressions, $0..$2
+ */
#define NUM_SUBS 3
+static void set_and_comp_regexp(cookie_dir_rec *dcfg,
+pool *p,
+const char *cookie_name)
+{
+/*
+ * The goal is to end up with this regexp,
+ * ^cookie_name=([^;]+)|;[\t]+cookie_name=([^;]+)
+ * with cookie_name obviously substituted either
+ * with the real cookie name set by the user in httpd.conf,
+ * or with the default COOKIE_NAME.
+ */
+dcfg-regexp_string = ap_pstrcat(p, ^, cookie_name,
+ =([^;]+)|;[ \t]+, cookie_name,
+ =([^;]+), NULL);
+dcfg-regexp = ap_pregcomp(p, dcfg-regexp_string, REG_EXTENDED);
+}
+
static int spot_cookie(request_rec *r)
{
cookie_dir_rec *dcfg = ap_get_module_config(r-per_dir_config,
@@ -353,6 +372,11 @@
dcfg-style = CT_UNSET;
dcfg-format = CF_NORMAL;
dcfg-enabled = 0;
+/*
+ * In case the user does not use the CookieName directive,
+ * we need to compile the regexp for the default cookie name.
+ */
+set_and_comp_regexp(dcfg, p, COOKIE_NAME);
return dcfg;
}
@@ -437,18 +461,10 @@
{
cookie_dir_rec *dcfg = (cookie_dir_rec *) mconfig;
-/* The goal is to end up with this regexp,
- * ^cookie_name=([^;]+)|;[ \t]+cookie_name=([^;]+)
- * with cookie_name
- * obviously substituted with the real cookie name set by the
- * user in httpd.conf. */
-dcfg-regexp_string = ap_pstrcat(cmd-pool, ^, name,
- =([^;]+)|;[ \t]+, name,
- =([^;]+), NULL);
-
dcfg-cookie_name = ap_pstrdup(cmd-pool, name);
-dcfg-regexp = ap_pregcomp(cmd-pool, dcfg-regexp_string,
REG_EXTENDED);
+set_and_comp_regexp(dcfg, cmd-pool, name);
+
if (dcfg-regexp == NULL) {
return Regular expression could not be compiled.;
}
Re: [1.3 PROPOSAL] call prctl(PR_SET_DUMPABLE)
+1 ! Jeff Trawick wrote: configure-time checks would used to check for availability (certain Linux only); the syscall would be made in the same situations as 2.x (if CoredumpDirectory has been set and we're starting as root) no patch yet, just wondering if anybody objects for some reason and/or there is a chance of picking up some +1s provided that the patch is reasonable -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [1.3 PATCH] log error if returning 500
+1
On Jan 12, 2004, at 11:42 AM, Jeff Trawick wrote:
2.x already does this
Index: src/modules/standard/mod_mime_magic.c
===
RCS file: /home/cvs/apache-1.3/src/modules/standard/mod_mime_magic.c,v
retrieving revision 1.51
diff -u -r1.51 mod_mime_magic.c
--- src/modules/standard/mod_mime_magic.c 1 Jan 2004 13:32:56
- 1.51
+++ src/modules/standard/mod_mime_magic.c 12 Jan 2004 16:38:45 -
@@ -832,9 +832,13 @@
r-content_encoding = tmp;
}
-/* detect memory allocation errors */
+/* detect memory allocation or other errors */
if (!r-content_type ||
(state == rsl_encoding !r-content_encoding)) {
+ap_log_rerror(APLOG_MARK, APLOG_NOERRNO | APLOG_ERR, r,
+ MODNAME : unexpected state %d; could be caused
by bad
+ data in magic file,
+ state);
return HTTP_INTERNAL_SERVER_ERROR;
}
Proposal: Allow ServerTokens to specify Server header completely
I'd like to get some sort of feedback concerning the idea of having ServerTokens not only adjust what Apache sends in the Server header, but also allow the directive to fully set that info. For example: ServerTokens Set Aporche/3.5 would cause Apache to send Aporche/3.5 as the Server header. Some people want to be able to totally obscure the server type.
Re: Proposal: Allow ServerTokens to specify Server header completely
Colm MacCarthaigh wrote: On Tue, Jan 13, 2004 at 03:04:30PM +0100, Lars Eilebrecht wrote: - It's only security by obscurity and providing such a security feature may be misleading for our users. - We don't want people to obfuscate the server name, do we? It's a terrible terrible terrible idea, and makes auditing your own network much much harder, but it's really a decision for administrators to make - if they want to shoot themselves in the foot, let them :) Most admins never compile apache :) It's from various admins, using open source and commercial versions of Apache that I've rec'd the request from. One request from an admin was to make it *easier* to audit his network, by allowing each machine to have a slightly different real name. Compiling several dozens of versions of Apache to do this is nasty. :) And yes, the FAQ specifically addresses this, but we already don't really honor it all that much (what other rationale is there for ServerTokens other than obfuscation? :) ). -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Proposal: Allow ServerTokens to specify Server header completely
Ivan Ristic wrote: As Lars said (and I agree), it has nothing to do with security. Why do you provide such a feature then? Because I believe that changing the signature prevents some automated tools from attacking the server. So, the signature does matter. Without a doubt. Look at how many exploits grep on not only the name of the server but also the version. I didn't propose this to create (yet another) heated discussion, simply to suggest that we take ServerTokens to its logical conclusion based on some requests I've seen. :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Proposal: Allow ServerTokens to specify Server header completely
Lars Eilebrecht wrote: According to Jim Jagielski: I didn't propose this to create (yet another) heated discussion, too late ;) simply to suggest that we take ServerTokens to its logical conclusion based on some requests I've seen. :) Sorry, but I don't see this as the logical conclusion of the ServerTokens directive. Being able to manage what third-party modules put in the server header is one thing, but changing the header to an arbitrary think does not seem logical to me, nor is it a security feature. ServerTokens allows more than just the removal of the module descriptions. For what other reason does the ability to go from Apache/2.0.49-dev (Unix) to Apache/2.0.49-dev to Apache/2.0 to Apache/2 to Apache provide rather than ways to obscure relative information about this specific build of Apache? Certainly Admins do this because I don't want people to know what specific version of Apache I'm using. I'm not really as Pro this enhancement as it may seem :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Proposal: Allow ServerTokens to specify Server header completely
Mads Toftum wrote: On Tue, Jan 13, 2004 at 09:35:15AM -0500, Jim Jagielski wrote: Without a doubt. Look at how many exploits grep on not only the name of the server but also the version. So it is ok to be vulnerable - as long as it isn't obvious? Of course not. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [1.3 PATCH] issue prctl(PR_SET_DUMPABLE) where available
+1 On Jan 13, 2004, at 9:54 AM, Jeff Trawick wrote: Rather than using multiple symbols (HAVE_SYS_PRCTL_H, HAVE_PRCTL), which would add to the CFLAGS, there is a single symbol HAVE_SET_DUMPABLE which is defined via CFLAGS if all prerequisites are met.
[OT] Incoming FAX to Email gateway s/w
Offlist, please contact me regarding suggestions on various (incoming) FAX-to-Email solutions. Not the normal send a FAX by sending an Email but receive an incoming FAX, image-ize it (TIFF, JPG, whatever) and send via Email to someone. tia.
Re: [1.3 PATCH] a different take on forensics
Anyway +1 (untested) for the core patch. +1 (tested) on the core-patch... I'm mulling over whether it should be included by default or, at least, runtime configurable :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: cvs commit: apache-1.3/src/modules/standard mod_usertrack.c
[EMAIL PROTECTED] wrote: Log: don't use Cookie2 for reading cookie data Did I miss the discussions on these? ALL development is still carried out on dev@, even if it's just a review/rehash of what's in the bug reports. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Time for 1.3.30??
I'd like to float the idea of releasing 1.3.30 soonish. Not only are there enough changes to warrant a release, but also to coincide with the changeover to AL 2.0. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Time for 2.0.49, WAS: Re: Time for 1.3.30??
We have a showstopper, don't we? On Feb 18, 2004, at 12:34 PM, Sander Striker wrote: On Wed, 2004-02-18 at 15:28, Jim Jagielski wrote: I'd like to float the idea of releasing 1.3.30 soonish. Not only are there enough changes to warrant a release, but also to coincide with the changeover to AL 2.0. In response to this, how do we feel about doing 2.0.49 aswell? Sander -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Time for 1.3.30??
On Feb 18, 2004, at 1:19 PM, Jeff Trawick wrote: Jim Jagielski wrote: I'd like to float the idea of releasing 1.3.30 soonish. Not only are there enough changes to warrant a release, but also to coincide with the changeover to AL 2.0. one question: who would support putting the 1.3 versions of mod_backtrace and mod_whatkilledus in experimental? I saw statements from 2 or 3 folks that seemed interested and I'd be happy to address the outstanding comments and suggestions (fix the directive names, escape the request info written by whatkilledus, allow mod_backtrace to be built on FreeBSD since there is a libexecinfo available there with the required function). No integration with the build planned unless somebody else wants to deal with the AP_ENABLE_EXCEPTION_HOOK flag ;) +1 on adding to experimental! -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: apr/apr-util python dependence
Greg Stein wrote: I hate to chime in here, but I must agree. Things have certainly come a long way when the build/configure system tried to be as LCD (lowest common denominator) as possible. And it was a recursive make solution which we're trying to fix. If you can come up with an LCD approach which has a single top-level Makefile, then please feel free. If we require all this extra stuff, then, at least to my mind, it means that we need to rethink not just patch. Oh, come on. For somebody building straight from CVS, to add a Python dependence? Okay, so it caught a few people unawares. We make changes like that all the time. But this one is not hard to solve. In any case, this whole notion of rewrite as a shell script just isn't going to fly. :) No, I have no solutions, nor did I mean to imply that: o Such a solution is trivial o That the solution used was done with no thought of impact to developers. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [PATCH] SSL not sending close alert message
Cliff Woolley wrote: On Tue, 24 Feb 2004, Joe Orton wrote: I wasn't sure whether or not this EOC bucket type should go in APR-util or httpd. Filtering gurus, what say ye? That bit looks OK to me otherwise with a licence header added to the new file. I say httpd. +1 -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Bug? in 1.3 htdigest?
+1
On Mar 2, 2004, at 10:41 AM, Thom May wrote:
* Thom May ([EMAIL PROTECTED]) wrote :
Hey guys,
just wondering why we use system(copy...)/system(cp...) in htdigest
in 1.3,
when the netware option seems to be more secure?
The patch attached just rips out the ifdef and uses the netware code
globally.
No complaints? Suggestions?
I'll commit tonight then?
-Thom
Index: htdigest.c
===
RCS file: /home/cvs/apache-1.3/src/support/htdigest.c,v
retrieving revision 1.39
diff -u -r1.39 htdigest.c
--- htdigest.c 20 Feb 2004 22:02:24 - 1.39
+++ htdigest.c 29 Feb 2004 18:50:18 -
@@ -152,7 +152,6 @@
}
-#ifdef NETWARE
static void copy_file(FILE *target, FILE *source)
{
static char line[MAX_STRING_LEN];
@@ -161,7 +160,6 @@
putline(target, line);
}
}
-#endif
int main(int argc, char *argv[])
{
@@ -239,14 +237,7 @@
}
fclose(f);
fclose(tfp);
-#ifndef NETWARE
-#if defined(OS2) || defined(WIN32)
-sprintf(command, copy \%s\ \%s\, tn, argv[1]);
-#else
-sprintf(command, cp %s %s, tn, argv[1]);
-#endif
-system(command);
-#else
+
if (!(tfp = fopen(tn, r))) {
fprintf(stderr, Could not open temp file.\n);
exit(1);
@@ -258,7 +249,6 @@
}
copy_file(f, tfp);
-#endif
unlink(tn);
return 0;
}
Time for 1.3.30?
There are a few open patches floating about, but in general I think we're close to a point where we should seriously consider 1.3.30. I volunteer to be RM... I'd like to shoot for mid-late next week for a release. Comments? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [PROPOSAL] Move httpd to the subversion repository
I would +1 moving over after release of 2.0.49 and 1.3.30... :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: 2.0.49 (rc3) tarballs available, WAS: Re: 2.0.49 (rc2) tarballs
Bill Stoddard wrote: Sander Striker wrote: You can find -rc3 in the usual place. The differences with rc2 are: - mod_cgid fix - docs update - windows build fix Sander Quick sniff on Windows 2000 looks good. Bill Quick sniff on Sol8 and OS X 10.3.3 also looks good. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
fix_hostname() in 1.3.30-dev broken
Ugg... fix_hostname() in 1.3.30-dev (and previous) are broken such that it does *not* update parsed_uri with the port and port_str value from the Host header. This means that with a request like: % telnet localhost GET / HTTP/1.1 Host: foo: that the '' port value from the Host header is ignored! 2.0 handles this correctly. This implies also that UseCanonicalName Off is still broken, since it's ignoring the port provided in the Host header. So we correctly adjust r-hostname but not port_str/port
Re: fix_hostname() in 1.3.30-dev broken
Roy T. Fielding wrote: Ugg... fix_hostname() in 1.3.30-dev (and previous) are broken such that it does *not* update parsed_uri with the port and port_str value from the Host header. This means that with a request like: % telnet localhost GET / HTTP/1.1 Host: foo: that the '' port value from the Host header is ignored! When is fix_hostname() used? If it is used anywhere other than ProxyPass redirects, then it must ignore that port value. To do otherwise would introduce a security hole in servers that rely on port blocking at firewalls. I agree that ProxyPass needs to know that port number, but that should be handled within the proxy itself. fix_hostname() is used by ap_update_vhost_from_headers() which is called immediately after all request headers have been read. The reason is that we need to adjust r-hostname to reflect what was sent in Host: Either the behavior in 2.0 is wrong, or 1.3 is, because 2.0 uses the port number provided in Host: to adjust the parsed_uri.port value, whereas 1.3 does not. And UseCanonicalName explicitly states that if Off, that Apache will use the Hostname *and* Port provided by the client, which leads me to think that 2.0 is correct... Whatever uses ap_get_server_port() would use the Port number included in the Host: header. This includes mod_vhost_alias, mod_proxy, mod_rewrite and Apache itself when it creates self- referential URLs (hence UseCanonicalName). Note that it's ONLY when UseCanonicalName is Off that this is an issue, and the SysAdmin no doubt has reasons for it :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
[PATCH] Re: fix_hostname() in 1.3.30-dev broken
Whatever uses ap_get_server_port() would use the Port number
included in the Host: header. This includes mod_vhost_alias,
mod_proxy, mod_rewrite and Apache itself when it creates self-
referential URLs (hence UseCanonicalName).
Note that it's ONLY when UseCanonicalName is Off that this is
an issue, and the SysAdmin no doubt has reasons for it :)
Index: src/main/http_vhost.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_vhost.c,v
retrieving revision 1.37
diff -u -r1.37 http_vhost.c
--- src/main/http_vhost.c 16 Feb 2004 22:29:33 - 1.37
+++ src/main/http_vhost.c 24 Mar 2004 16:14:15 -
@@ -662,6 +662,7 @@
char *host = ap_palloc(r-pool, strlen(r-hostname) + 1);
const char *src;
char *dst;
+char *port_str;
/* check and copy the host part */
src = r-hostname;
@@ -679,6 +680,7 @@
goto bad;
}
if (*src == ':') {
+port_str = src + 1;
/* check the port part */
while (*++src) {
if (!ap_isdigit(*src)) {
@@ -687,8 +689,12 @@
}
if (src[-1] == ':')
goto bad;
-else
+else {
+/* a known good port value */
+r-parsed_uri.port_str = ap_pstrdup(r-pool, port_str);
+r-parsed_uri.port = atoi(r-parsed_uri.port_str);
break;
+}
}
*dst++ = *src++;
}
Bugz: 27023
The core issue with this bug is that we trample on any pre-existing Set-Cookie headers by willy-nilly overwriting our response header with that generated by the origin server. Should we honor existing Set-Cookie headers, or is that non-compliant?
Apache 1.3 - One more item for release
I want to resolve the below item before we release... I've talked it over with Roy, and we both agree some sort of more intelligent overlaying is required, although treating Set-Cookie as a special case for now is fine... Note that 2.x also seems affected by this and should be resolved. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27023
Re: Apache 1.3 - One more item for release
I'm hoping to carve out some time tomorrow... but if someone else has some free time :) On Mar 29, 2004, at 3:50 PM, Jeff Trawick wrote: Jim Jagielski wrote: I want to resolve the below item before we release... I've talked it over with Roy, and we both agree some sort of more intelligent overlaying is required, although treating Set-Cookie as a special case for now is fine... Note that 2.x also seems affected by this and should be resolved. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27023 is somebody working on a different fix than what is in the PR?
1.3.30 ...
I've removed the last SHOWSTOPPER for the 1.3.30 release. I think we're ready for 1.3.30... anyone disagree?
Re: Any 1.3.30 tarball feeback??
Hmmm... I feel that this is safe... If you commit I'll reTAG and reroll. PS: The real reason I don't think we should toss the tag is that this only affect Win people, a small minority in the 1.3 world. So the diffs between the current tarball (should it leak) and this one would be minimal and limited to Win people. On Apr 12, 2004, at 3:06 PM, William A. Rowe, Jr. wrote: At 12:33 PM 4/12/2004, Jim Jagielski wrote: Any comments on the 1.3.30 release candidate tarball? The mod_rewrite.dsw was patched to find the ws2_32.lib required when we modified rewrite. Unfortunately, the .mak file was not updated at the same time. IDE builds (what I tested a week ago) work just fine, but command line builds on win32 were broke. My inclination, if nobody disagrees, is to commit the .mak file updates and push the tag, rerolling those files into the 1.3.30 .tar.gz and including them as fixed in the .msi/.exe win32 installers. Being derrived files which are nothing more than gatekeepers (it builds or it doesn't, and does not change functionality) I'm not seeing a reason to toss this tag. Thoughts? Bill -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
1.3.3x digest/nonce issue
There is a known bug/issue in the current implementation of mod_digest regarding the nonce. I am looking to have this plugged for our next 1.3 release. There are 2 suggested patches, which I will post under separate Emails. I will also adjust STATUS to reflect these 2 potential patches. PLEASE look these over! I would still like to get a 1.3 release out soon. My expectation is that we will toss 1.3.30...
[PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
On Apr 13, 2004, at 11:13 AM, Jim Jagielski wrote:
There is a known bug/issue in the current implementation
of mod_digest regarding the nonce. I am looking to
have this plugged for our next 1.3 release.
There are 2 suggested patches, which I will post under
separate Emails. I will also adjust STATUS to reflect
these 2 potential patches.
PLEASE look these over! I would still like to get a
1.3 release out soon. My expectation is that we
will toss 1.3.30...
Candidate patch #1:
Index: src/main/http_core.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v
retrieving revision 1.331
diff -u -r1.331 http_core.c
--- src/main/http_core.c16 Feb 2004 22:29:33 - 1.331
+++ src/main/http_core.c17 Mar 2004 14:02:15 -
@@ -193,6 +193,9 @@
if (new-ap_auth_name) {
conf-ap_auth_name = new-ap_auth_name;
}
+if (new-ap_auth_nonce) {
+conf-ap_auth_nonce = new-ap_auth_nonce;
+}
if (new-ap_requires) {
conf-ap_requires = new-ap_requires;
}
@@ -534,6 +537,32 @@
return conf-ap_auth_name;
}
+API_EXPORT(const char *) ap_auth_nonce(request_rec *r)
+{
+core_dir_config *conf;
+conf = (core_dir_config *)ap_get_module_config(r-per_dir_config,
+ core_module);
+if (conf-ap_auth_nonce)
+ return conf-ap_auth_nonce;
+
+/* Ideally we'd want to mix in some per-directory style
+ * information; as we are likely to want to detect replay
+ * across those boundaries and some randomness. But that
+ * is harder due to the adhoc nature of .htaccess memory
+ * structures, restarts and forks.
+ *
+ * But then again - you should use AuthNonce in your config
+ * file if you care. So the adhoc value should do.
+ */
+return ap_psprintf(r-pool,%lu%lu%lu%lu%lu%s,
+ *(unsigned long *)((r-connection-local_addr).sin_addr ),
+ *(unsigned long *)ap_user_name,
+ *(unsigned long *)ap_listeners,
+ *(unsigned long *)ap_server_argv0,
+ *(unsigned long *)ap_pid_fname,
+ WHAT_THE_HECK_GOES_HERE?);
+}
+
API_EXPORT(const char *) ap_default_type(request_rec *r)
{
core_dir_config *conf;
@@ -2781,6 +2810,28 @@
return NULL;
}
+/*
+ * Load an authorisation nonce into our location configuration, and
+ * force it to be in the 0-9/A-Z realm.
+ */
+static const char *set_authnonce (cmd_parms *cmd, void *mconfig, char
*word1)
+{
+core_dir_config *aconfig = (core_dir_config *)mconfig;
+int i;
+
+aconfig-ap_auth_nonce = ap_escape_quotes(cmd-pool, word1);
+
+if (strlen(aconfig-ap_auth_nonce) 510)
+ return AuthNonce length limited to 510 chars for browser
compatibility;
+
+for(i=0;istrlen(aconfig-ap_auth_nonce );i++)
+ if (!ap_isalnum(aconfig-ap_auth_nonce [i]))
+ return AuthNonce limited to 0-9 and A-Z range for browser
compatibility;
+
+return NULL;
+}
+
+
#ifdef _OSD_POSIX /* BS2000 Logon Passwd file */
static const char *set_bs2000_account(cmd_parms *cmd, void *dummy,
char *name)
{
@@ -3395,6 +3446,9 @@
An HTTP authorization type (e.g., \Basic\) },
{ AuthName, set_authname, NULL, OR_AUTHCFG, TAKE1,
The authentication realm (e.g. \Members Only\) },
+{ AuthNonce, set_authnonce, NULL, OR_AUTHCFG, TAKE1,
+ An authentication token which should be different for each logical
realm. \
+ A random value or the servers IP may be a good choise.\n },
{ Require, require, NULL, OR_AUTHCFG, RAW_ARGS,
Selects which authenticated users or groups may access a protected
space },
{ Satisfy, satisfy, NULL, OR_AUTHCFG, TAKE1,
Index: src/main/http_protocol.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_protocol.c,v
retrieving revision 1.332
diff -u -r1.332 http_protocol.c
--- src/main/http_protocol.c16 Feb 2004 22:29:33 - 1.332
+++ src/main/http_protocol.c17 Mar 2004 14:02:17 -
@@ -33,6 +33,7 @@
#include util_date.h /* For parseHTTPdate and BAD_DATE */
#include stdarg.h
#include http_conf_globals.h
+#include util_md5.h /* For digestAuth */
#define SET_BYTES_SENT(r) \
do { if (r-sent_bodyct) \
@@ -1348,11 +1349,25 @@
API_EXPORT(void) ap_note_digest_auth_failure(request_rec *r)
{
+/* We need to create a nonce which:
+ * a) changes all the time (see r-request_time)
+ *below and
+ * b) of which we can verify that it is our own
+ *fairly easily when it comes to veryfing
+ *the digest coming back in the response.
+ * c) and which as a whole should not
+ *be unlikely to be in use anywhere else.
+ */
+char * nonce_prefix = ap_md5(r-pool,
+ (unsigned char *)
+ ap_psprintf(r-pool, %s%lu,
+ ap_auth_nonce(r), r-request_time));
+
ap_table_setn(r-err_headers_out,
r-proxyreq == STD_PROXY
[PATCH] Candidate 2: Re: 1.3.3x digest/nonce issue
On Apr 13, 2004, at 11:13 AM, Jim Jagielski wrote:
There is a known bug/issue in the current implementation
of mod_digest regarding the nonce. I am looking to
have this plugged for our next 1.3 release.
There are 2 suggested patches, which I will post under
separate Emails. I will also adjust STATUS to reflect
these 2 potential patches.
PLEASE look these over! I would still like to get a
1.3 release out soon. My expectation is that we
will toss 1.3.30...
Candidate patch #2
Index: src/ApacheCore.def
===
RCS file: /home/cvs/apache-1.3/src/ApacheCore.def,v
retrieving revision 1.35
diff -u -r1.35 ApacheCore.def
--- src/ApacheCore.def 18 Jun 2002 04:19:46 - 1.35
+++ src/ApacheCore.def 18 Dec 2003 21:25:49 -
@@ -447,3 +447,4 @@
ap_getline @439
ap_get_chunk_size @440
ap_escape_logitem @441
+ap_auth_nonce @442
Index: src/ApacheCoreOS2.def
===
RCS file: /home/cvs/apache-1.3/src/ApacheCoreOS2.def,v
retrieving revision 1.13
diff -u -r1.13 ApacheCoreOS2.def
--- src/ApacheCoreOS2.def 22 May 2003 09:45:28 - 1.13
+++ src/ApacheCoreOS2.def 18 Dec 2003 21:25:50 -
@@ -430,3 +430,4 @@
ap_escape_logitem @441
ap_popenf_ex @442
ap_psocket_ex @443
+ ap_auth_nonce @444
Index: src/CHANGES
===
RCS file: /home/cvs/apache-1.3/src/CHANGES,v
retrieving revision 1.1914
diff -u -r1.1914 CHANGES
--- src/CHANGES 14 Dec 2003 18:16:49 - 1.1914
+++ src/CHANGES 18 Dec 2003 21:25:56 -
@@ -1,5 +1,11 @@
Changes with Apache 1.3.30
+ *) SECURITY: CAN-2003-0987 (cve.mitre.org)
+ Verification as to whether the nonce returned in the client
response
+ is one we issued ourselves by means of a AuthNonce secret exposed
as an
+ md5(). See mod_digest documentation for more details. The
experimental
+ mod_auth_digest.c does not have this issue. [Dirk-Willem van
Gulik]
+
*) Fix mod_include's expression parser to recognize strings correctly
even if they start with an escaped token. [André Malo]
Index: src/include/ap_mmn.h
===
RCS file: /home/cvs/apache-1.3/src/include/ap_mmn.h,v
retrieving revision 1.65
diff -u -r1.65 ap_mmn.h
--- src/include/ap_mmn.h14 Dec 2003 18:16:49 - 1.65
+++ src/include/ap_mmn.h18 Dec 2003 21:25:56 -
@@ -244,6 +244,8 @@
*ap_popenf_ex() and ap_psocket_ex().
* 19990320.15 - ap_is_recursion_limit_exceeded()
* 19990320.16 - ap_escape_errorlog_item()
+ * 19990320.17 - ap_auth_nonce() and ap_auth_nonce added
+ *in core_dir_config.
*/
#define MODULE_MAGIC_COOKIE 0x41503133UL /* AP13 */
Index: src/include/http_core.h
===
RCS file: /home/cvs/apache-1.3/src/include/http_core.h,v
retrieving revision 1.71
diff -u -r1.71 http_core.h
--- src/include/http_core.h 7 Jul 2003 00:34:09 - 1.71
+++ src/include/http_core.h 18 Dec 2003 21:25:56 -
@@ -162,6 +162,7 @@
API_EXPORT(const char *) ap_auth_type (request_rec *);
API_EXPORT(const char *) ap_auth_name (request_rec *);
+API_EXPORT(const char *) ap_auth_nonce (request_rec *);
API_EXPORT(int) ap_satisfies (request_rec *r);
API_EXPORT(const array_header *) ap_requires (request_rec *);
@@ -312,6 +312,9 @@
*/
ap_flag_e cgi_command_args;
+/* Digest auth. */
+char *ap_auth_nonce;
+
} core_dir_config;
/* Per-server core configuration */
Index: src/main/http_core.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v
retrieving revision 1.327
diff -u -r1.327 http_core.c
--- src/main/http_core.c17 Nov 2003 17:14:53 - 1.327
+++ src/main/http_core.c18 Dec 2003 21:25:58 -
@@ -236,6 +236,9 @@
if (new-ap_auth_name) {
conf-ap_auth_name = new-ap_auth_name;
}
+if (new-ap_auth_nonce) {
+conf-ap_auth_nonce = new-ap_auth_nonce;
+}
if (new-ap_requires) {
conf-ap_requires = new-ap_requires;
}
@@ -577,6 +580,29 @@
return conf-ap_auth_name;
}
+API_EXPORT(const char *) ap_auth_nonce(request_rec *r)
+{
+core_dir_config *conf;
+conf = (core_dir_config *)ap_get_module_config(r-per_dir_config,
+ core_module);
+if (conf-ap_auth_nonce)
+ return conf-ap_auth_nonce;
+
+/* Ideally we'd want to mix in some per-directory style
+ * information; as we are likely to want to detect replay
+ * across those boundaries and some randomness. But that
+ * is harder due to the adhoc nature of .htaccess memory
+ * structures, restarts and forks.
+ *
+ * But then again - you
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
Jeff Trawick wrote: Candidate patch #1: This was my patch to an earlier patch to address some build issues and point out a run-time problem with a sprintf call I guess I need to go through patch 2 and verify that everything was addressed, and/or point out the missing pieces (after I get my tax returns finished and in the mail). It looks like the other suggested patch incorporates some of your comments, but not all. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
As an aside, I am unable to successfully apply either patch to the current apache-1.3 tree (not fuzz related, just bad patches, eg: patching file src/modules/standard/mod_digest.c Hunk #2 FAILED at 329. 1 out of 2 hunks FAILED -- saving rejects to file src/modules/standard/mod_digest.c.rej or File to patch: src/main/http_core.c patching file src/main/http_core.c Hunk #1 succeeded at 202 (offset -34 lines). patch: malformed patch at line 132: API_EXPORT(const char *) ap_default_type(request_rec *r) This is under OS X 10.3.3... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
Joshua Slive wrote: I do have one question about this: Is anyone actually using mod_digest? I was under the impression that there doesn't exist any client that can interoperate with this module (as opposed to mod_auth_digest, which supports modern clients). If this is true, why don't we just delete the darn thing? AFAIK, it's the IE variety that fails to work with mod_digest, but most others do. I have no idea on how widely used the module itself is, but our options are: 1. Remove it 2. Demote it to experimental with a note that it suffers from this bug 3. Fix it. 4. Ignore it. #4 is not under consideration at present. #3 seems like the right thing to do, but only if it doesn't result in 1.3.3x being delayed for weeks. #2 is reasonable, if only we didn't have to worry about the CVS aspects of the move (yeah svn!) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
[PATCH 1.3.30/31] Re: 1.3.3x digest/nonce issue
On Apr 13, 2004, at 11:13 AM, Jim Jagielski wrote:
There is a known bug/issue in the current implementation
of mod_digest regarding the nonce. I am looking to
have this plugged for our next 1.3 release.
There are 2 suggested patches, which I will post under
separate Emails. I will also adjust STATUS to reflect
these 2 potential patches.
PLEASE look these over! I would still like to get a
1.3 release out soon. My expectation is that we
will toss 1.3.30...
Suggested patch:
Index: src/ApacheCore.def
===
RCS file: /home/cvs/apache-1.3/src/ApacheCore.def,v
retrieving revision 1.35
diff -u -u -r1.35 ApacheCore.def
--- src/ApacheCore.def 18 Jun 2002 04:19:46 - 1.35
+++ src/ApacheCore.def 14 Apr 2004 15:57:44 -
@@ -447,3 +447,4 @@
ap_getline @439
ap_get_chunk_size @440
ap_escape_logitem @441
+ap_auth_nonce @442
Index: src/ApacheCoreOS2.def
===
RCS file: /home/cvs/apache-1.3/src/ApacheCoreOS2.def,v
retrieving revision 1.13
diff -u -u -r1.13 ApacheCoreOS2.def
--- src/ApacheCoreOS2.def 22 May 2003 09:45:28 - 1.13
+++ src/ApacheCoreOS2.def 14 Apr 2004 15:57:45 -
@@ -430,3 +430,4 @@
ap_escape_logitem @441
ap_popenf_ex @442
ap_psocket_ex @443
+ ap_auth_nonce @444
Index: src/CHANGES
===
RCS file: /home/cvs/apache-1.3/src/CHANGES,v
retrieving revision 1.1935
diff -u -u -r1.1935 CHANGES
--- src/CHANGES 9 Apr 2004 17:01:50 - 1.1935
+++ src/CHANGES 14 Apr 2004 15:58:14 -
@@ -1,5 +1,11 @@
Changes with Apache 1.3.31
+ *) SECURITY: CAN-2003-0987 (cve.mitre.org)
+ Verification as to whether the nonce returned in the client
response
+ is one we issued ourselves by means of a AuthNonce secret exposed
as an
+ md5(). See mod_digest documentation for more details. The
experimental
+ mod_auth_digest.c does not have this issue. [Dirk-Willem van
Gulik]
+
Changes with Apache 1.3.30
*) Fix memory corruption problem with ap_custom_response() function.
Index: src/include/ap_mmn.h
===
RCS file: /home/cvs/apache-1.3/src/include/ap_mmn.h,v
retrieving revision 1.67
diff -u -u -r1.67 ap_mmn.h
--- src/include/ap_mmn.h16 Feb 2004 22:25:08 - 1.67
+++ src/include/ap_mmn.h14 Apr 2004 15:58:23 -
@@ -201,6 +201,8 @@
*ap_popenf_ex() and ap_psocket_ex().
* 19990320.15 - ap_is_recursion_limit_exceeded()
* 19990320.16 - ap_escape_errorlog_item()
+ * 19990320.17 - ap_auth_nonce() and ap_auth_nonce added
+ *in core_dir_config.
*/
#define MODULE_MAGIC_COOKIE 0x41503133UL /* AP13 */
Index: src/include/http_core.h
===
RCS file: /home/cvs/apache-1.3/src/include/http_core.h,v
retrieving revision 1.74
diff -u -u -r1.74 http_core.h
--- src/include/http_core.h 29 Mar 2004 18:35:29 - 1.74
+++ src/include/http_core.h 14 Apr 2004 15:58:24 -
@@ -119,6 +119,7 @@
API_EXPORT(const char *) ap_auth_type (request_rec *);
API_EXPORT(const char *) ap_auth_name (request_rec *);
+API_EXPORT(const char *) ap_auth_nonce (request_rec *);
API_EXPORT(int) ap_satisfies (request_rec *r);
API_EXPORT(const array_header *) ap_requires (request_rec *);
@@ -313,6 +314,9 @@
* direct command line parameters or argv elements?
*/
ap_flag_e cgi_command_args;
+
+/* Digest auth. */
+char *ap_auth_nonce;
} core_dir_config;
Index: src/main/http_core.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v
retrieving revision 1.332
diff -u -u -r1.332 http_core.c
--- src/main/http_core.c29 Mar 2004 18:35:29 - 1.332
+++ src/main/http_core.c14 Apr 2004 15:58:42 -
@@ -202,6 +202,9 @@
if (new-ap_auth_name) {
conf-ap_auth_name = new-ap_auth_name;
}
+if (new-ap_auth_nonce) {
+conf-ap_auth_nonce = new-ap_auth_nonce;
+}
if (new-ap_requires) {
conf-ap_requires = new-ap_requires;
}
@@ -543,6 +546,32 @@
return conf-ap_auth_name;
}
+API_EXPORT(const char *) ap_auth_nonce(request_rec *r)
+{
+core_dir_config *conf;
+conf = (core_dir_config *)ap_get_module_config(r-per_dir_config,
+ core_module);
+if (conf-ap_auth_nonce)
+ return conf-ap_auth_nonce;
+
+/* Ideally we'd want to mix in some per-directory style
+ * information; as we are likely to want to detect replay
+ * across those boundaries and some randomness. But that
+ * is harder due to the adhoc nature of .htaccess memory
+ * structures, restarts and forks.
+ *
+ * But then again - you
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
On Apr 14, 2004, at 1:57 PM, Ben Laurie wrote: Correct - it is a nonce-seed. AuthDigestNonce -- AuthDigestSeed or AuthDigestNonceSeed ? It should be identical across an XS realm - but different from realm to realm. If one realm is used on multiple servers (e.g. non sticky loadbalancing) it should be identical across those servers. As a -lot- of different site's use common realm names (such as 'DAV' or 'webfolder') so it should not be set to the same as the realm. Hence the IP address advice for single servers. (This is the problem I found in the wild - recycle a captured wire digest from a common realm name such as 'webfolder', 'dav', 'ical' and use it on a totally different server to which the user uses the same convenience username and password). Right. We should be more explicit about the threat model. To that end, how about something like AuthDigestRealmSeed as the name? I think that makes it clearer, yes. +1
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
I'd like to propose that I simply commit the revised patch to CVS for us to poke around with/test/review, etc... My guess is that we'll ship with something similar and this will provide, at least, a nice framework.
Re: cvs commit: httpd-docs-1.3/htdocs/manual/mod mod_digest.html
On Apr 15, 2004, at 3:53 PM, Geoffrey Young wrote: +(December 2003), most major browsers support digest +authentication. However, the only major browsers which support +the old digest authentication format are a href=http://www.opera.com/;Opera 4.0/a, +a href=http://www.microsoft.com/windows/ie/;MS Internet +Explorer 5.0/a and a href=http://www.w3.org/Amaya/;Amaya/a. that still doesn't sound quite right to me. here is how I recall the state of affairs last I checked all the browsers (admittedly over a year ago, but most browsers don't remove features, and MSIE is still borked by all accounts). feel free to adopt it (or not) or alter the wording/formatting at will - I was just trying to help things a bit. Excellent improvement! Thanks.
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
I'm suggesting changing the static string WHAT_THE_HECK_GOES_HERE? in ap_auth_nonce() to ap_get_server_name()... comments?
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
Jeff Trawick wrote: see my prior comment on that section of code ;) Dirk's later patch got rid of extra %s in the format string, so zap the last %s as well as my lame WHAT_THE_HECK_GOES_HERE?. There was som discussion on making ServerName a semi-realm-based aspect of the nonce... Anybody want to think about what happens if we're so unlucky that the ap_user_name or ap_pid_fname string with '\0' is smaller than sizeof(unsigned long) and just happens to be allocated at the end of a page? Unlikely, but still... Maybe those are supposed to be ap_user_name, ap_listeners, etc.? In which case we could use our native '%pp' format (which we should be doing anyway). From my read of it, I think that Dirk's intent was to use the *addresses* of those parameters, so yeah, I think that's not quite right. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue
On Apr 16, 2004, at 9:39 AM, Jim Jagielski wrote: Jeff Trawick wrote: Anybody want to think about what happens if we're so unlucky that the ap_user_name or ap_pid_fname string with '\0' is smaller than sizeof(unsigned long) and just happens to be allocated at the end of a page? Unlikely, but still... Maybe those are supposed to be ap_user_name, ap_listeners, etc.? In which case we could use our native '%pp' format (which we should be doing anyway). From my read of it, I think that Dirk's intent was to use the *addresses* of those parameters, so yeah, I think that's not quite right. Maybe something like this: Index: src/main/http_core.c === RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v retrieving revision 1.333 diff -u -r1.333 http_core.c --- src/main/http_core.c15 Apr 2004 15:51:51 - 1.333 +++ src/main/http_core.c16 Apr 2004 13:46:03 - @@ -563,13 +563,12 @@ * But then again - you should use AuthDigestRealmSeed in your config * file if you care. So the adhoc value should do. */ -return ap_psprintf(r-pool,%lu%lu%lu%lu%lu%s, - *(unsigned long *)((r-connection-local_addr).sin_addr ), - *(unsigned long *)ap_user_name, - *(unsigned long *)ap_listeners, - *(unsigned long *)ap_server_argv0, - *(unsigned long *)ap_pid_fname, - WHAT_THE_HECK_GOES_HERE?); +return ap_psprintf(r-pool,%pp%pp%pp%pp%pp, + (void *)((r-connection-local_addr).sin_addr ), + (void *)ap_user_name, + (void *)ap_listeners, + (void *)ap_server_argv0, + (void *)ap_pid_fname); } API_EXPORT(const char *) ap_default_type(request_rec *r)
1.3.31 short term schedule
My schedule for 1.3.31 is a tag and roll on Monday/Tuesday with a release on Friday (I will be traveling Tuesday and Thursday and in Seattle on Wednesday)... It's my belief that the nonce issue is settled with the code currently in HEAD, but would approciate a few more eyes on it. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Request for feedback - UseCanonicalPort
On May 11, 2004, at 6:18 PM, Brad Nicholes wrote: +1 to Bill's comment. I don't quite understand what is confusing and why we would need UseCanonicalPort. IMO, all that really needs to be done is to fix UseCanonicalName so that it works according to the documentation. As was explained previously, when UseCanonicalName is OFF, both 1.3 and 2.1 try to pull the port information from the client in any way that it can before defaulting to values supplied in the .conf file or the hard-coded standard port values. The problem with the 2.0 tree is that it only looks for the port value as part of the URL before defaulting to the known values. Before using known values, it should look for the port in the connection information (ie. r-connection-local_addr-port). The current result can produce incorrect port information when a port value is not supplied as part of the URL. According to the documentation, if UseCanonicalName is OFF it should construct the self-referential information from the client. By skipping the port information held in the connection record, it isn't doing what it claims to be doing. The rub is that with UCN Off, we either choose the port number sent within the Host header or we choose the actual physical port number; we *never* choose the configured or default port. The docs say: With UseCanonicalName off Apache will form self-referential URLs using the hostname and port supplied by the client if any are supplied (otherwise it will use the canonical name, as defined above). which is does not do currently but *is* a viable and required implementation in some cases, as you know since IIRC you were the one to adjust 2.1 to the current behavior to correctly handle some problems you were seeing. However, the 2.0 case is also required when Apache (on port 8000, eg) is behind a load-balancer (on port 80) and the LB splices the request to Apache. In this case, if Apache needs to create a self-ref with UCN Off, then it returns the hostname from Host (as it should) but assuming no port information it returns port 8000: LB: www.foo.com:80 Apache: foo1.foo.com:8000 Apache should send www.foo.com:80, but instead it'll send www.foo.com:8000 unless the client appends ':80' to the Host header :/ So both the 1.3/2.1 and the 2.0 methods may be required for different environments. Which means that at least there should be a 4th option (after On, Off and DNS) which says Ignore physical port or alternatively Use physical port. But use_canonical_name is a bitfield of width 2, which doesn't give us enough room, so in order to prevent breaking the API (we can't expand it), we could tack another element to the end of core_dir_config to extend how the port is determined, hence UseCanonicalPort.
Re: Request for feedback - UseCanonicalPort
Do you mean that 2.0 now works correctly? In that case maybe the short-term is to use the 2.0 method for both 1.3 and 2.1, until we can figure out a better method... I think the 2.0 method is likely more correct than the 1.3/2.1 one, at least as a default implementation. On May 12, 2004, at 1:13 PM, Brad Nicholes wrote: Now I understand better, thanks. The issue that prompted me to implement the fixes for 2.1 and 1.3 manifested themselves primarily on NetWare due to the way NetWare implements the SSL functionality (NetWare doesn't use mod_ssl). In some cases requrests on an SSL port were being redirected to port 80 rather than the port that they came from. This problem has been solved in 2.x for NetWare by implementing the default_port hook in mod_nw_ssl and doing something similar in 1.3. It sounds like there are really two issues that need to be addressed at least for the 2.0 branch although they could be tied together. One issue, as you have described, is how or when to use a port value which UseCanonicalPort would solve. The other issue, which has already been address in 1.3 and 2.1, is where to get the port value from. Allowing Apache to look at the physical port would need to be added to 2.0 as it does in 1.3 and 2.1. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Wednesday, May 12, 2004 7:28:24 AM On May 11, 2004, at 6:18 PM, Brad Nicholes wrote: +1 to Bill's comment. I don't quite understand what is confusing and why we would need UseCanonicalPort. IMO, all that really needs to be done is to fix UseCanonicalName so that it works according to the documentation. As was explained previously, when UseCanonicalName is OFF, both 1.3 and 2.1 try to pull the port information from the client in any way that it can before defaulting to values supplied in the .conf file or the hard-coded standard port values. The problem with the 2.0 tree is that it only looks for the port value as part of the URL before defaulting to the known values. Before using known values, it should look for the port in the connection information (ie. r-connection-local_addr-port). The current result can produce incorrect port information when a port value is not supplied as part of the URL. According to the documentation, if UseCanonicalName is OFF it should construct the self-referential information from the client. By skipping the port information held in the connection record, it isn't doing what it claims to be doing. The rub is that with UCN Off, we either choose the port number sent within the Host header or we choose the actual physical port number; we *never* choose the configured or default port. The docs say: With UseCanonicalName off Apache will form self-referential URLs using the hostname and port supplied by the client if any are supplied (otherwise it will use the canonical name, as defined above). which is does not do currently but *is* a viable and required implementation in some cases, as you know since IIRC you were the one to adjust 2.1 to the current behavior to correctly handle some problems you were seeing. However, the 2.0 case is also required when Apache (on port 8000, eg) is behind a load-balancer (on port 80) and the LB splices the request to Apache. In this case, if Apache needs to create a self-ref with UCN Off, then it returns the hostname from Host (as it should) but assuming no port information it returns port 8000: LB: www.foo.com:80 Apache: foo1.foo.com:8000 Apache should send www.foo.com:80, but instead it'll send www.foo.com:8000 unless the client appends ':80' to the Host header :/ So both the 1.3/2.1 and the 2.0 methods may be required for different environments. Which means that at least there should be a 4th option (after On, Off and DNS) which says Ignore physical port or alternatively Use physical port. But use_canonical_name is a bitfield of width 2, which doesn't give us enough room, so in order to prevent breaking the API (we can't expand it), we could tack another element to the end of core_dir_config to extend how the port is determined, hence UseCanonicalPort.
Re: Request for feedback - UseCanonicalPort
What I've done, for the 1.3 case, is make honoring the physical port number (ala 2.1) a compile-time flag... This should hold us off until we figure out a better way to do this, so it may get backed out when that happens. In the meantime, 1.3.32-dev will operate as does 2.0, which is, I think, the implementation of least astonishment. On May 12, 2004, at 1:59 PM, Brad Nicholes wrote: It works correctly for the NetWare SSL case that I was running into. But I don't think it works correctly for the case that you are describing. The patches that I added to 2.0 and 1.3 are NetWare specific. The 2.0 patch is in mod_nw_ssl.c which implements the default_port hook and the 1.3 patch was added to netware/os.c by redefining ap_default_port() to ap_os_default_port(). These patches resolve the issue of where does the port come from. Neither of them address the issue of when or how the port value should be used. So I believe that the example you gave of: correctly handle some problems you were seeing. However, the 2.0 case is also required when Apache (on port 8000, eg) is behind a load-balancer (on port 80) and the LB splices the request to Apache. In this case, if Apache needs to create a self-ref with UCN Off, then it returns the hostname from Host (as it should) but assuming no port information it returns port 8000: LB: www.foo.com:80 Apache: foo1.foo.com:8000 Apache should send www.foo.com:80, but instead it'll send www.foo.com:8000 unless the client appends ':80' to the Host header :/ would still be broken. In fact searching back through the mailing list archieve for [EMAIL PROTECTED], Matthieu Estrade's issue with ap_get_server_port() sounded similar to the example that you gave, but it is what prompted the 2.1 patch and the backport proposal. (http://marc.theaimsgroup.com/?l=apache-httpd-devm=103798747720589w=2 ) Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Wednesday, May 12, 2004 11:32:30 AM Do you mean that 2.0 now works correctly? In that case maybe the short-term is to use the 2.0 method for both 1.3 and 2.1, until we can figure out a better method... I think the 2.0 method is likely more correct than the 1.3/2.1 one, at least as a default implementation. On May 12, 2004, at 1:13 PM, Brad Nicholes wrote: Now I understand better, thanks. The issue that prompted me to implement the fixes for 2.1 and 1.3 manifested themselves primarily on NetWare due to the way NetWare implements the SSL functionality (NetWare doesn't use mod_ssl). In some cases requrests on an SSL port were being redirected to port 80 rather than the port that they came from. This problem has been solved in 2.x for NetWare by implementing the default_port hook in mod_nw_ssl and doing something similar in 1.3. It sounds like there are really two issues that need to be addressed at least for the 2.0 branch although they could be tied together. One issue, as you have described, is how or when to use a port value which UseCanonicalPort would solve. The other issue, which has already been address in 1.3 and 2.1, is where to get the port value from. Allowing Apache to look at the physical port would need to be added to 2.0 as it does in 1.3 and 2.1. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Wednesday, May 12, 2004 7:28:24 AM On May 11, 2004, at 6:18 PM, Brad Nicholes wrote: +1 to Bill's comment. I don't quite understand what is confusing and why we would need UseCanonicalPort. IMO, all that really needs to be done is to fix UseCanonicalName so that it works according to the documentation. As was explained previously, when UseCanonicalName is OFF, both 1.3 and 2.1 try to pull the port information from the client in any way that it can before defaulting to values supplied in the .conf file or the hard-coded standard port values. The problem with the 2.0 tree is that it only looks for the port value as part of the URL before defaulting to the known values. Before using known values, it should look for the port in the connection information (ie. r-connection-local_addr-port). The current result can produce incorrect port information when a port value is not supplied as part of the URL. According to the documentation, if UseCanonicalName is OFF it should construct the self-referential information from the client. By skipping the port information held in the connection record, it isn't doing what it claims to be doing. The rub is that with UCN Off, we either choose the port number sent within the Host header or we choose the actual physical port number; we *never* choose the configured or default port. The docs say: With UseCanonicalName off Apache will form self-referential URLs using the hostname and port supplied by the client if any are supplied (otherwise it will use the canonical name, as
Re: Request for feedback - UseCanonicalPort
Well, at least with 2.0, that's the way ServerName is documented... nd is right... the actual physical port can never be, afaik, 0, so wherever that is in the logic path, that's the final end :) But on thinking it even more deeply, having Apache return the physical port can always be done via setting it explicitly in ServerName (for 2.x) or adding a Port directive to the VirtualHost tag for 1.3... Many people may not be aware that: Port 8080 VirtualHost 10.0.0.1 ServerName foo Port 80 /VirtualHost is possible and legal in 1.3 and makes the Vhost return foo:80 with UCN On and, with UCN Off will force Apache to set the port to 80 if the client doesn't add one to Host. So if with UCN Off they want the physical port to be sent, ensure the value for Port is whatever the actual listening port is; if they want some other port, then it can be set. But it doesn't cause the Vhost to actually *do* anything on port 80. On May 12, 2004, at 2:47 PM, Brad Nicholes wrote: I guess the part that confuses me most is why is honoring the physical port number a bad thing? If you look at the implementation of ap_get_server_port() in the 2.0 branch, the function determines the port value by: USE_CANONICAL_NAME_OFF || USE_CANONICAL_NAME_DNS 1- parsed_uri.port 2- server-port 3- ap_default_port() USE_CANONICAL_NAME_ON 1- server-port 2- local_addr-port 3- ap_default_port() Notice that in the USE_CANONICAL_NAME_ON it checks the physical port before calling ap_default_port() but USE_CANONICAL_NAME_OFF || DNS doesn't. Shouldn't the sources of port information be the same for both cases, just a different order? The patch in the 2.1 branch just fixes this. But, it was pointed out by nd that if the local_addr-port could never be 0 then the call to ap_default_port() is dead code and would never be called. But if it could be 0 then what is the difference between no port and a valid port value of 0. This is the reason why the backport proposal has stagnated in the STATUS file. I don't know what the correct answer is but I do believe that honoring the physical port number is a good thing and should be checked somehow.
[PATCH 1.3] New UseCanonicalName option
One way of handling the diffs between how 1.3 and 2.0 handles
UCN Off.
Index: src/CHANGES
===
RCS file: /home/cvs/apache-1.3/src/CHANGES,v
retrieving revision 1.1939
diff -u -r1.1939 CHANGES
--- src/CHANGES 7 May 2004 14:43:04 - 1.1939
+++ src/CHANGES 11 May 2004 16:06:56 -
@@ -1,5 +1,12 @@
Changes with Apache 1.3.32
+ *) Add new option 'Off20x' to UseCanonicalName to allow Apache 1.3
+ to follow the method used by Apache 2.0.x to determine the
+ Port value to used for the canonical name. The difference
+ is that 'Off' uses the actual socket port number if the
+ client doesn't send a port value in Host; under 2.0.x,
+ we ignore the physical port number.
+
Changes with Apache 1.3.31
*) SECURITY: CAN-2003-0987 (cve.mitre.org)
Index: src/include/ap_mmn.h
===
RCS file: /home/cvs/apache-1.3/src/include/ap_mmn.h,v
retrieving revision 1.68
diff -u -r1.68 ap_mmn.h
--- src/include/ap_mmn.h15 Apr 2004 15:51:51 - 1.68
+++ src/include/ap_mmn.h11 May 2004 16:06:57 -
@@ -203,6 +203,8 @@
* 19990320.16 - ap_escape_errorlog_item()
* 19990320.17 - ap_auth_nonce() and ap_auth_nonce added
*in core_dir_config.
+ * 19990320.18 - increase bitfield size of use_canonical_name
+ from 2 to 4 in core_dir_config.
*/
#define MODULE_MAGIC_COOKIE 0x41503133UL /* AP13 */
Index: src/include/http_core.h
===
RCS file: /home/cvs/apache-1.3/src/include/http_core.h,v
retrieving revision 1.75
diff -u -r1.75 http_core.h
--- src/include/http_core.h 15 Apr 2004 15:51:51 - 1.75
+++ src/include/http_core.h 11 May 2004 16:06:57 -
@@ -225,11 +225,12 @@
signed int content_md5 : 2; /* calculate Content-MD5? */
-#define USE_CANONICAL_NAME_OFF (0)
-#define USE_CANONICAL_NAME_ON(1)
-#define USE_CANONICAL_NAME_DNS (2)
-#define USE_CANONICAL_NAME_UNSET (3)
-unsigned use_canonical_name : 2;
+#define USE_CANONICAL_NAME_OFF(0)
+#define USE_CANONICAL_NAME_ON (1)
+#define USE_CANONICAL_NAME_DNS(2)
+#define USE_CANONICAL_NAME_OFF20X (3)
+#define USE_CANONICAL_NAME_UNSET (4)
+unsigned use_canonical_name : 4;
/* since is_fnmatch(conf-d) was being called so frequently in
* directory_walk() and its relatives, this field was created and
Index: src/main/http_core.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v
retrieving revision 1.335
diff -u -r1.335 http_core.c
--- src/main/http_core.c3 May 2004 20:15:26 - 1.335
+++ src/main/http_core.c11 May 2004 16:07:00 -
@@ -783,9 +783,7 @@
/* There are two options regarding what the name of a server is. The
* canonical name as defined by ServerName and Port, or the client's
- * name as supplied by a possible Host: header or full URI. We never
- * trust the port passed in the client's headers, we always use the
- * port of the actual socket.
+ * name as supplied by a possible Host: header or full URI.
*
* The DNS option to UseCanonicalName causes this routine to do a
* reverse lookup on the local IP address of the connectiona and use
@@ -802,7 +800,8 @@
d = (core_dir_config *)ap_get_module_config(r-per_dir_config,
core_module);
-if (d-use_canonical_name == USE_CANONICAL_NAME_OFF) {
+if (d-use_canonical_name == USE_CANONICAL_NAME_OFF ||
+d-use_canonical_name == USE_CANONICAL_NAME_OFF20X) {
return r-hostname ? r-hostname : r-server-server_hostname;
}
if (d-use_canonical_name == USE_CANONICAL_NAME_DNS) {
@@ -850,6 +849,10 @@
cport ? cport :
r-server-port ? r-server-port :
ap_default_port(r);
+} else if (d-use_canonical_name == USE_CANONICAL_NAME_OFF20X) {
+port = r-parsed_uri.port_str ? r-parsed_uri.port :
+ r-server-port ? r-server-port :
+ap_default_port(r);
} else { /* d-use_canonical_name == USE_CANONICAL_NAME_ON */
port = r-server-port ? r-server-port :
cport ? cport :
@@ -2396,11 +2399,14 @@
else if (strcasecmp(arg, off) == 0) {
d-use_canonical_name = USE_CANONICAL_NAME_OFF;
}
+else if (strcasecmp(arg, off20x) == 0) {
+d-use_canonical_name = USE_CANONICAL_NAME_OFF20X;
+}
else if (strcasecmp(arg, dns) == 0) {
d-use_canonical_name = USE_CANONICAL_NAME_DNS;
}
else {
-return parameter must be 'on', 'off', or 'dns';
+return parameter must be 'on', 'off', 'off20x' or 'dns';
}
return NULL;
}
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http
Re: [PATCH 1.3] New UseCanonicalName option
On May 11, 2004, at 12:28 PM, Jim Jagielski wrote: One way of handling the diffs between how 1.3 and 2.0 handles UCN Off. *) SECURITY: CAN-2003-0987 (cve.mitre.org) Index: src/include/ap_mmn.h === RCS file: /home/cvs/apache-1.3/src/include/ap_mmn.h,v retrieving revision 1.68 diff -u -r1.68 ap_mmn.h --- src/include/ap_mmn.h15 Apr 2004 15:51:51 - 1.68 +++ src/include/ap_mmn.h11 May 2004 16:06:57 - @@ -203,6 +203,8 @@ * 19990320.16 - ap_escape_errorlog_item() * 19990320.17 - ap_auth_nonce() and ap_auth_nonce added *in core_dir_config. + * 19990320.18 - increase bitfield size of use_canonical_name + from 2 to 4 in core_dir_config. */ Ignore this for now... widening the bitfield breaks API compatibility... I'm mulling over a CanonicalPort directive... we need more granular control over how we determine the canonical port number...
Request for feedback - UseCanonicalPort
IMO, we need more control over the port number that Apache determines to be canonical beyond that which is provided by UseCanonicalName, simply because there are so many options and permutations which are possible and applicable for different environments. To that end, instead of overloading UseCanonicalName (and breaking the API), I'm working on UseCanonicalPort. Before I spend lots of time on this, I need to get a feel for whether this is an itch others think need scratching and would vote for including in 2.0 (I'm working on 1.3, 2.0 and 2.1 patches)...
Status of 1.3.31...
Looking for negative (do-not-release) feedback for the 1.3.31 RC tarballs...
TR of 1.3.31
I plan to TR 1.3.31 most likely tomorrow... speak now or forever hold your peace.
Re: TR of 1.3.31
On Apr 26, 2004, at 1:42 PM, Geoffrey Young wrote: I don't think the mod_digest.html stuff I sent was integrated, even though it seemed people were happy with the wording. but I didn't want to just commit it until the RM officially said so :) not that these docs are all that critical of an issue... so :) +1 Yeah, commit those changes.
Re: 1.3.31?
The TR of 1.3.31 will be done within the next day or 2 with a formal release likely early next week. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Apache 1.3.31 RC Tarballs available
Via: http://httpd.apache.org/dev/dist/ I'd like to announce and release the 11th.
Re: Apache 1.3.31 RC Tarballs available
I have made the tarballs unavailable from the below URL. People should contact me directly to obtain the correct URL... Sander Temme wrote: --Apple-Mail-1-423850141 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On May 7, 2004, at 8:15 AM, Jim Jagielski wrote: Via: http://httpd.apache.org/dev/dist/ I'd like to announce and release the 11th. Except Slashdot beat you to the punch: http://apache.slashdot.org/. S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF --Apple-Mail-1-423850141 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGezCCAzQw ggKdoAMCAQICAwvmIjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMzEyMDYwODM5WhcNMDUwMzEyMDYwODM5WjCBhDEfMB0GA1UE AxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEfMB0GCSqGSIb3DQEJARYQc2FuZGVyQHRlbW1lLm5l dDEdMBsGCSqGSIb3DQEJARYOc2FuZGVyQG1hYy5jb20xITAfBgkqhkiG9w0BCQEWEnNjdGVtbWVA YXBhY2hlLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALDRNkTCskDD/q/7gGYW w8vdRiZ8aTIC8i+f5nCsFMF2o/tLC0oskhPzk0l5v8RxYKRa1DVJOUEW/RVoLbp0woyQnSBtNpjB XUHdSZ+9r+K3MdGLMDStdJbz6lW4ck4sJbJcfoZx7/ZhprFhYDUaS3v7mWZpCzV8uHwL1psJ+I/k nV3bksbE2FK9E6/TAFPh6af1aCKGSs+d7El/xhAFnPVlfHEaeOOdY+GieHYCgr6AVJlms8bjr7ad bbb30VoWOuzeX49aEBbWAsPy6pljEMvssD2AdJ2ZvcCxzPk4A5g6D0f0wQwpzPM7qsCiK1zMCLH4 pSzD6XmtXmBwnNpZvIECAwEAAaNRME8wPwYDVR0RBDgwNoEQc2FuZGVyQHRlbW1lLm5ldIEOc2Fu ZGVyQG1hYy5jb22BEnNjdGVtbWVAYXBhY2hlLm9yZzAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEB BAUAA4GBAIrTKvUSlPyS43Xm5fowg8vEU1yNctMIbl3CwBjhwn6UlVLh4iPy2gNW2ai2hDJv6K3E RraoZ6B2zOZ0oEVYw9on2oG3LVsORRTdji5SmwG7VhwuPxvM8+IFwlP7m3wsrSTTZ/YyPqNANR1I h16WNPKw6nsMbxfidJd/TpV7guYwMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRow GAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNl cyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZI hvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEz MDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Ia dr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+ K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1Ro YXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRow GAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9l TzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgML5iIwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMDQwNTA3MTkyMjIyWjAjBgkqhkiG9w0BCQQxFgQUZFQO5eXJ246GdqVInhw3fFf2ni8w eAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECAwvmIjB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAgML5iIwDQYJKoZIhvcNAQEBBQAEggEACuTr81U5YRYrQq8RZru90GQTQGi5 HZCXyv5eYCRnlKQtTIXP1wyauPopSb6QByXmCPOIpngSxrKEXSczvHtP7h7AXd0y1TtLDGJCLeID vut23ovdoiXtSQmG0L3I3tDaBq/uVaLvEFqwRqmuVefLklxc+Om9W12OarJtncMk12lva20UhXuj 1pIDbnp10N25bocZcqvVs2Uf6Ri11sZDs04BkZiL22PONzFXSlMc5L1wk7V4lws80Bar7dDvyuAV TFGY60MKayXEK5VzrxlIYhnVVXa25A5W26RpqNYib4sN98V5/vXD1CGeOt0qxzZVS6ZufZMqFfjI ok78Zo5gdw== --Apple-Mail-1-423850141-- -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
UseCanonicalName Off
In the 2.1 STATUS file we see: * When UseCanonicalName is set to OFF, allow ap_get_server_port to check r-connection-local_addr-port before defaulting to server-port or ap_default_port() This is, in fact, the behavior in 1.3.31... The idea being that with UseCanonicalName Off, we rely on what the client tells us, so even when it doesn't explicitly tell us a port number, we use the port number that we are talking to it on, which would make sense. However, I can also see cases where this may be confusing or not-desired, so I would propose another option for UseCanonicalName, like 'Client' which would be the 1.3.31 method and the 2.1 method. This would address the issues that the implementation in 1.3.31 and 2.1 were designed to handle, but also allow the old traditional Off behavior... I'm proposing this both for 2.0 as well as 1.3.32-dev. Comments??
Re: Apache 1.3.31 RC Tarballs available
The trouble is that we need to perform *some* sort of quality control out there... The option is as soon as we have a tarball out, it's immediately released, in which case why even bother with a test or RC candidate. We need to, IMO, impose some sort of order and process on how we release s/w, and the simple fact that we have RC tarballs out there doesn't cut it. It's certainly a problem that we've had for some time, especially when you consider the times when releases are really security related... I would hate having some sort of private release mailing list where we can really test RC tarballs in a semi secure environment before they are released in general, but I can't see us simply saying our release procedure is we throw a tarball out there and 2-3 days after we do that we Announce it :) Aaron Bannert wrote: Why is it bad if people download the RC version and test it? Frankly, I really don't mind if slashdot or anyone else broadcasts that we have an RC tarball available. If anything it's a good thing. We don't make any guarantees about our code anyway, so whether or not we call it a GA release is just a courtesy to our users. Sheesh, this just seems like we're turning down would-be beta-testers! Please put the tarballs back up, and please ignore the press. -aaron On May 7, 2004, at 12:28 PM, Jim Jagielski wrote: I have made the tarballs unavailable from the below URL. People should contact me directly to obtain the correct URL... Sander Temme wrote: On May 7, 2004, at 8:15 AM, Jim Jagielski wrote: Via: http://httpd.apache.org/dev/dist/ I'd like to announce and release the 11th. Except Slashdot beat you to the punch: http://apache.slashdot.org/. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Apache 1.3.31 RC Tarballs available
Aaron Bannert wrote: I believe that a strict QA process actually hurts the quality of OSS projects like Apache. We have a gigantic pool of talented users who would love to give us a hand by testing our latest and greatest in every contorted way imaginable. But we're holding out on them. We're saying that we know better than they do. I don't think we do. Sure, we should be testing our code, but there's absolutely no way that we can be perfect. Closely held ivory-tower QA doesn't scale any better at the ASF than it does at a proprietary company. But the QA that comes out of widely distributed release-candidates _does_ scale. Why don't we let the teeming masses have their fill? I don't consider us a closely held ivory-tower QA and I would say that if anyone knows of a talented pool of users would would like to test RCs, then we should have a mechanism to use them. That was the intent for the current/stable-testers list, but we've never really used that as we should have. The problem is really 2 fold: 1. The tarballs were being mistakenly described as the official release. It's not released until we say so. I think it's our responsibility to ensure that people aren't mistakenly running pre-release s/w under the impression that it is release. 2. That when all goes well, and the RC tarballs are approved, they aren't changed at all... We are testing, really, the accuracy of the tarball itself. This add some complexity to the whole process. I've been thinking over changing the 1.3 release process and us actually tagging a tree as RC, creating actual 1.3.x-rc1 tarballs and people testing that, and having those very, very open, but having the actual *release* tarballs somewhat closed (again, to test the viability of the tarball, not the code). -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Move apache-1.3 to Subversion
I'd like to propose that the apache-1.3 tree be migrated over to subversion.
Re: Apache 1.3.31 RC Tarballs available
Aaron Bannert wrote: I still don't see why any stage in the release process should be closed, though. We don't make any guarantees about any of our code at any time, Well, yes, you're right, we don't make any guarantees, but certainly our intent and desire is that we produce the best quality code we can and that the Apache name is trusted and associated with quality. So sometimes we need to act in ways to hopefully ensure that :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Apache 1.3 to be moved to SVN
I believe that we've rec'd quite a few +1s on the issue of moving apache-1.3 to subversion and no -1s. Let's give it a few more days, but unless we hear otherwise, we should consider making it official Monday or so (the 24th). At that point, we can ask the infrastructure team to perform the required magic. :)
Re: mod_ldap testing
On May 21, 2004, at 9:43 PM, Graham Leggett wrote: Hi all, The outstanding bugs for mod_ldap* in Bugzilla have gone from 38 down to 9 - single figures at last. There are 4 open segfault bugs - can y'all give the code a bit of a hammering to see if there are any gotchas left un-stomped-on. Cool...
Re: Move apache-1.3 to Subversion
On May 23, 2004, at 4:01 PM, Manoj Kasichainula wrote: On Mon, May 17, 2004 at 12:35:13AM +0200, Sander Striker wrote: There's only one thing for us to decide; how to define the layout under httpd/ in the SVN repository. e.g. .../ httpd/ trunk/ branches/ 1.3.x/ 2.0.x/ tags/ 2.0.49/ ... 1.3.31/ ... Sounds good. We should ponder a way to set up closed branches for security patches. Maybe they could be protected on a case-by-case basis, or we create a 4th top-level directory security-patches. Fine here, but does httpd-2.x need to move over for apache-1.3 to migrate to subversion?
Re: Move apache-1.3 to Subversion
Sander Striker wrote: On Mon, 2004-05-24 at 14:13, Jim Jagielski wrote: On May 23, 2004, at 4:01 PM, Manoj Kasichainula wrote: On Mon, May 17, 2004 at 12:35:13AM +0200, Sander Striker wrote: There's only one thing for us to decide; how to define the layout under httpd/ in the SVN repository. [...] Fine here, but does httpd-2.x need to move over for apache-1.3 to migrate to subversion? No, I was just giving the overall picture. Sander +1 then :)
Re: 1.3.31 regression affecting Front Page?
Hmm.. this was a patch suggested by Rasmus, iirc. Jeff Trawick wrote: Jeff Trawick wrote: This patch did it: http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.173r2=1.174 Backing out the patch also fixes a DAV regression. See http://issues.apache.org/bugzilla/show_bug.cgi?id=29237 See also http://issues.apache.org/bugzilla/show_bug.cgi?id=29257 http://www.rtr.com/fp2002disc/_disc2/0a71.htm -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: 1.3.31 regression affecting Front Page?
I've backed out that patch and asked Rasmus to send a replacemnet which addresses his specific problem but does not cause the below behavior. I'm tempted to release 1.3.32... Jeff Trawick wrote: This patch did it: http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/http_request.c?r1=1.173r2=1.174 See also http://issues.apache.org/bugzilla/show_bug.cgi?id=29257 http://www.rtr.com/fp2002disc/_disc2/0a71.htm -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: 1.3.31 regression affecting Front Page?
William A. Rowe, Jr. wrote: At 07:09 AM 5/28/2004, Jim Jagielski wrote: I've backed out that patch and asked Rasmus to send a replacemnet which addresses his specific problem but does not cause the below behavior. I'm tempted to release 1.3.32... Collect another week or few of data on other problems first, perhaps? Once the replacement patch arrives - we have a home for this over in /dist/httpd/patches/apply_to_1_3_31/, right? I'd also like to see a few other minor quibbles fixed, like the change of canonical name behavior. I do have to wrap my head around that issue still. Well, I didn't mean immediately :) I do mean to release 1.3.32 much sooner than previous 1.3 versions have been released, like sometime in June. Although I'm still mulling over the UCN issue (and when/how to have Apache sort through the logic flow of how to choose the correct port number), there are other patches that would be beneficial to fold in, like the various ones you provided. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: mod_proxy.so in Apache 2.0.49
g g wrote: I am trying to install Apache 2.0.49 on AIX 5.2 with proxy module enabled. I am build the source code using following options: 1)configure --prefix=Location --enable-so --enable-proxy 2)make 3)make install After the installation is complete, if we try to look for proxy module i.e. mod_proxy.so under modules folder of pache 2049 installation, we can't see the module. There are no .so files under modules directory. I also tried to look for the module library under whole apache installation. I couldn't find the proxy module library. Is there a separate way of installing proxy enabled apache 2.0.49? You aren't building the modules as DSOs, but are simply enabling DSO support via the above. So the modules are compiled in. Check out the enable-shared option
Re: 1.3.31 regression affecting Front Page?
I had sent private Email to your @apache.org address (since that's the one you use to provide HTTPD related patches). On Jun 8, 2004, at 5:10 PM, Rasmus Lerdorf wrote: Uh, I never received anything on this. Did you actually send me something? I'll have a look at addressing this issue. Releasing 1.3.32 without this fix would be a nasty backwards step. The original problem this fixes is serious. -Rasmus On Fri, 28 May 2004, Jim Jagielski wrote: I've backed out that patch and asked Rasmus to send a replacemnet which addresses his specific problem but does not cause the below behavior. I'm tempted to release 1.3.32... Jeff Trawick wrote: This patch did it: http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/main/ http_request.c?r1=1.173r2=1.174 See also http://issues.apache.org/bugzilla/show_bug.cgi?id=29257 http://www.rtr.com/fp2002disc/_disc2/0a71.htm -- == = Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: 1.3.31 regression affecting Front Page?
On Jun 9, 2004, at 3:24 PM, Rasmus Lerdorf wrote: I guess what we are agreeing on here is that the logic that sets keepalive to 0 is faulty and that is probably where the real fix lies. yeah... it's pretty inconsistent. Looking at ap_set_keepalive even after we know the connection will be closed, we set keepalive to 0, for example.
Re: Proxy Cookie Support (Bug #10722)
Nick Kew wrote: I recently patched bug 10722. My patch was against 2.0.49, for a Client who needed it in a hurry. I'm just porting it to 2.1-HEAD. In doing so, I find there's an existing patch that saves and restores cookies without rewriting the Domain and Path components. AFAICS my patch would/should supersede that one. But I'm reluctant to do so without understanding the purpose of the other patch. The other patch is at http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/proxy/proxy_http.c?r1=1.184r2=1.185 It appears just to merge Set-Cookie headers in r-err_headers_out with those in r-headers_out. The latter have just come from the backend (the server proxied). But how/why should there be (any) cookies in r-err_headers_out at this point? Presumably they'd be from the proxy rather than the backend? And why merge them into a normal 2xx response? This is so Cookies added my the local proxy server (Apache) via internal custom modules do not loose those cookies when used also as a proxy. If a module has added Cookie information we should honor that and maintain it as is. Roy and I talked about this and both agreed that it made sense hence the patch. In this case, it should NOT rewrite the domain/path info, since that would destroy the utility of that cookie, since it is a cookie generated by, and used by, the proxy server and not the origin server. Rewriting would make that bogus. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Proxy Cookie Support (Bug #10722)
Joe Schaefer wrote: But is the err_headers_out logic in proxy_http.c HEAD really ok? It appears to put a copy of r-err_headers_out into r-headers_out, so I'm wondering why this doesn't produce duplicates in the final response (ie. doesn't httpd add r-err_headers_out itself, in ap_http_header_filter)? It overlays the 2, so yes. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Proxy Cookie Support (Bug #10722)
Joe Schaefer wrote: Just to be sure we're on the same page- you agree here that HEAD will erroneously produce duplicates of any Set-Cookie headers in the proxy server's r-err_headers_out table. Sure looks like that :) It does not appear that err_headers_out is cleared in the proxy logic path so when Apache is ready to create the default response headers, the overlay will cause Cookies already in err_headers_out to be duplicated since they have been already added to headers_out after we've read the origin server response headers. So the apr_table_do(addit_dammit, save_table, r-err_headers_out, Set-Cookie, NULL); line should be removed. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
apachectl script enhancement
Anyone have any problem if we enhance apachectl a bit to allow for -v/-V printout? Like ./apachectl version | ./apachectl fullversion ?
Re: apachectl script enhancement
Joshua Slive wrote: On Mon, 28 Jun 2004, Jim Jagielski wrote: Anyone have any problem if we enhance apachectl a bit to allow for -v/-V printout? Like ./apachectl version | ./apachectl fullversion ? I don't understand. apachectl -v and apachectl -V work fine. (apachectl passess unknown parameters directly to httpd.) True, but I was thinking more in line with it being explicit, ala configtest. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Time for 1.3.32 ?
I'm floating the idea of releasing 1.3.32 shortly... Comments or thoughts?
Re: Time for 1.3.32 ?
Let's use STATUS :) =?ISO-8859-15?Q?Andr=E9?= Malo wrote: * Jeff Trawick [EMAIL PROTECTED] wrote: well, if you're going to be that way then consider my simple Win32 patch to fix reporting of proper error by spawnl(), which needs another +1 :) (see thread [1.3 PATCH] restore failing errno for Win32 spawn errors on this list) +1 from me for that errno patch ;) nd -- Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3) -- aus einer Rezension http://pub.perlig.de/books.html#apache2 -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Time for 1.3.32 ?
Yes, we do, and we're still waiting for a patch. However, I can't see us delaying 1.3.32 for an unreasonable amount of time. On Jul 5, 2004, at 10:54 AM, Rasmus Lerdorf wrote: We still have that outstanding issue of conn-keepalive being bogus in ap_die() because it hasn't been set yet and thus we can't discard the request body in situations where we really need to. See my previous long explanation of that problem. -Rasmus On Sat, 3 Jul 2004, Jim Jagielski wrote: Let's use STATUS :) =?ISO-8859-15?Q?Andr=E9?= Malo wrote: * Jeff Trawick [EMAIL PROTECTED] wrote: well, if you're going to be that way then consider my simple Win32 patch to fix reporting of proper error by spawnl(), which needs another +1 :) (see thread [1.3 PATCH] restore failing errno for Win32 spawn errors on this list) +1 from me for that errno patch ;) nd -- Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3) -- aus einer Rezension http://pub.perlig.de/books.html#apache2 -- == = Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: mod_dir and mod_cache
Since these modules are experimental (still), the backport procedure is (or should be) much more relaxed than with non-exp modules. Heck, I would almost say that anything added to the 2.1 tree for exp. modules should *always* be added to the 2.0 tree as well (for experimental modules). :) Bill Stoddard wrote: Brian Akins wrote: I think I missed the answer to this: Has the feature that prevents mod_cache from caching urls ending in / (as related to mod_dir) been fixed? If so, will this make it into 2.0? yes it has been fixed. I volunteer to help with the backport. Just need to get the votes to backport for each patch. Bill -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: httpd-2.2 release roadmap v0.1
Geoffrey Young wrote: so, can someone comment on what 2.2 (and the subsequent 2.3) mean for 2.0? that is, if everyday hacking is against 2.3 and we propose a new feature to backport, do we backport to both 2.2 and 2.0? or does it mean that 2.0 has reached end-of-life and we backport only to 2.2? just so I (and others) know what to expect... :) I would foresee only 1.3 and 2.2 being around and 2.0 being EOLed. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
