[PATCH] 2.0->2.1
This patch changes a lot of 2.0 references to 2.1. It doesn't get them all. Not all should change, anyway. In particular, most references in "Apache 2.0" in the docs are unchanged, because that requires a more careful review than the changes I've made here. Before I commit this, will this annoy anyone? I.e. does someone have a method planned for this? Otherwise, we can start with this and move from there. mod_dav has a lot of "DAV module for Apache 2.0". I didn't touch these. I think it should read "DAV module for Apache HTTPD". Not hard to infer that since it's in the 2.1 source tree that it's for 2.1. We may want to deprecate the use of "Apache" as referring to HTTPD anyway, as it can only get increasingly confusing as "Apache" is associated more and more projects over time. I'd guess we're already past the point where the typical user in our various communities thinks "we server" first when they hear "Apache". Also the version string in AB is still "2.0.blah". Maybe should become "2.1.0-dev", but I suppose that should wait until it needs to change. So long as it doesn't become "2.0.blah+1-dev", since branched along with the rest of httpd. -wsv Index: INSTALL === RCS file: /home/cvs/httpd-2.0/INSTALL,v retrieving revision 1.18 diff -w -u -d -r1.18 INSTALL --- INSTALL 26 Nov 2001 22:46:32 - 1.18 +++ INSTALL 7 Dec 2002 07:14:59 - @@ -5,7 +5,7 @@ -- For complete installation documentation, see [ht]docs/manual/install.html or - http://httpd.apache.org/docs-2.0/install.html + http://httpd.apache.org/docs-2.1/install.html $ ./configure --prefix=PREFIX $ make @@ -40,7 +40,7 @@ --enable-rewrite=shared \ --enable-speling=shared - The easiest way to find all of the configuration flags for Apache 2.0 + The easiest way to find all of the configuration flags for Apache 2.1 is to run ./configure --help. @@ -48,14 +48,14 @@ - For complete documentation, see [ht]docs/manual/platform/windows.html or - http://httpd.apache.org/docs-2.0/platform/windows.html. + http://httpd.apache.org/docs-2.1/platform/windows.html. The Apache/Win32 binaries are primarily distributed as a Windows Installer package (.msi), and may be available as a .zip file as well. These packages - are named apache-2.0.xx-win32-x86.msi and apache-2.0.xx-win32-x86.zip. + are named apache-2.1.xx-win32-x86.msi and apache-2.1.xx-win32-x86.zip. Please choose the .msi package if at all possible. - If you have unpacked a source distribution (named httpd-2.0-xx.zip, without + If you have unpacked a source distribution (named httpd-2.1-xx.zip, without any -win32-x86 notation) you must compile the package yourself, see the links mentioned above. Unless you intended to do this, please look again for the binary package from http://www.apache.org/dist/httpd/binaries/win32/ and @@ -85,7 +85,7 @@ comp.infosystems.www.servers.unix or comp.infosystems.www.servers.ms-windows. - Thanks for using the Apache HTTP Server, version 2.0. + Thanks for using the Apache HTTP Server, version 2.1. The Apache Software Foundation http://www.apache.org/ Index: LAYOUT === RCS file: /home/cvs/httpd-2.0/LAYOUT,v retrieving revision 1.1 diff -w -u -d -r1.1 LAYOUT --- LAYOUT 30 May 2002 18:17:16 - 1.1 +++ LAYOUT 7 Dec 2002 07:15:00 - @@ -1,7 +1,7 @@ -The httpd-2.0 Source Tree LAYOUT +The httpd-2.1 Source Tree LAYOUT -./ Top-Level httpd-2.0 Root Directory +./ Top-Level httpd-2.1 Root Directory ABOUT_APACHE .. Overview of the Apache HTTP Server LAYOUT This file describing the source tree Index: README === RCS file: /home/cvs/httpd-2.0/README,v retrieving revision 1.12 diff -w -u -d -r1.12 README --- README 23 Apr 2002 12:18:35 - 1.12 +++ README 7 Dec 2002 07:15:00 - @@ -24,7 +24,7 @@ The documentation available as of the date of this release is included in HTML format in the docs/manual/ directory. The most up-to-date documentation can be found at - http://httpd.apache.org/docs-2.0/. + http://httpd.apache.org/docs-2.1/. Installation @@ -86,5 +86,5 @@ University of Cambridge, England. The original software is available from ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ - Apache 2.0 relies heavily on the use of autoconf and libtool to provide + Apache 2 relies heavily on the use of autoconf and libtool to provide a build environment. Index: README.platforms ===
Can't compile HEAD on Linux
I can't compile current HEAD of httpd-2.0 due to the compiler errors shown in http://www.sebastian-bergmann.de/stuff/apr-util.txt. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Re: cvs commit: httpd-2.0/server .cvsignore Makefile.in
On Fri, 6 Dec 2002 22:06:11 -0800, Wilfredo Sánchez wrote:
> Is this because expat is in a directory containing "apr" in the path?
Quite possibly.
> What does "apu-config --includes" output for you? Yeah, mine is:
I did actually include this in my post:
>> My apu-config --include prints:
>>
>> -I/Apache/httpd-2.0/srclib/apr-util/include
>> -I/Apache/httpd-2.0/srclib/apr-util/xml/expat/lib
> -I/usr/local/apache/include/apr-0 -I/usr/local/BerkeleyDB.4.1/include
>-I/usr/local/include
>
>because I build expat separately and put it in /usr/local.
>
> I'm a little worried about this patch because since you switched it
>to only scan away preceding spaces, this only works so long at apr's
>include dir is first, but it looks like that's always the case unless
>we change apu-config, so OK.
I wasn't sure about it either, that's why I posted a "this works for me"
patch rather than just commiting it.
>On Tuesday, December 3, 2002, at 05:59 AM, Brian Havard wrote:
>
>> On Tue, 03 Dec 2002 23:24:46 +1000 (EST), Brian Havard wrote:
>>
>>> On Fri, 29 Nov 2002 12:09:55 -0800, Wilfredo Sánchez wrote:
>>>
Yuck OK. $< is used for the ApacheCoreOS2.def, though I suppose
that
only matters for OS/2. I won't touch it.
>>>
>>> That should be fine as only gnu make is used to build on OS/2. There's
>>> another problem though that breaks the OS/2 build & I'm not sure what
>>> the
>>> right fix is. What's happening is that exports.c tries to #include
>>> "winconfig.h" which it finds in apr-util/xml/expat/lib/winconfig.h
>>> which
>>> fails as that tries to #include windows.h.
>>>
>>> I don't think the expat library headers should be included by
>>> EXPORT_DIRS,
>>> I can't see any reason to force all expat functions into the Apache
>>> core.
>>
>> On further investigation it appears the culprit is in configure.in
>> where:
>>
>> APU_INCLUDEDIR=`$apu_config --includes | sed 's|^.*-I\([[^ ]]*apr[[^
>> ]]*\).*$|\1|'`
>>
>> which extracts the LAST -I directory when it needs to extract the
>> first.
>> My apu-config --include prints:
>>
>> -I/Apache/httpd-2.0/srclib/apr-util/include
>> -I/Apache/httpd-2.0/srclib/apr-util/xml/expat/lib
>>
>> so I get the expat headers which I don't want & I don't get the
>> apr-util
>> headers which I do want. This fixes it for me:
>>
>> Index: configure.in
>> ===
>> RCS file: /home/cvs/httpd-2.0/configure.in,v
>> retrieving revision 1.236
>> diff -u -r1.236 configure.in
>> --- configure.in 29 Nov 2002 07:34:20 - 1.236
>> +++ configure.in 3 Dec 2002 12:52:21 -
>> @@ -100,7 +100,7 @@
>> APR_ADDTO(LDFLAGS, `$apu_config --ldflags`)
>> APR_ADDTO(INCLUDES, `$apu_config --includes`)
>> APU_BINDIR=`$apu_config --bindir`
>> -APU_INCLUDEDIR=`$apu_config --includes | sed 's|^.*-I\([[^ ]]*apr[[^
>> ]]*\).*$|\1|'`
>> +APU_INCLUDEDIR=`$apu_config --includes | sed 's|^ *-I\([[^ ]]*apr[[^
>> ]]*\).*$|\1|'`
>>
>> echo $ac_n "${nl}Configuring PCRE regular expression library ...${nl}"
>>
--
__
| Brian Havard | "He is not the messiah! |
| [EMAIL PROTECTED] | He's a very naughty boy!" - Life of Brian |
--
Re: [PATCH] Allowing extended characters in LDAP authentication...
At 03:42 PM 12/6/2002, Brad Nicholes wrote: >This patch adds a new directive "AuthLDAPConvertFromLanguage" to mod_auth_ldap >that allows the admin to either define a specific language when converting the user >ID to UTF8 of try to derive the language from the header. Ewww... charsets aren't languages. '...ByLanguage' would be more appropriate. More to the point... all headers suffer from this problem. If we are going to address dealing with non-utf-8 headers into a canonical utf-8 form, I'd prefer some directive to deal with this across the board. Win32 would actually prefer to deal in utf-8 identifiers, and if we invest the energy in 'fixups' for one canonical header (user/passwords) then we aught to think about dealing with them all in one place. And that place wouldn't be in ldap, but more likely in a module like mod_charset_headers or something that will just deal with all of the implications of HTTP/1.1's inbound 'opaque' high-bit characters; perhaps we fix outbound header fields as well. Just my (selfish) 2c :) Bill p.s. honest - hadn't even read on to Andre's response when I wrote the response above, but +1 to his observations :)
Re: cvs commit: httpd-2.0/server .cvsignore Makefile.in
Is this because expat is in a directory containing "apr" in the path?
What does "apu-config --includes" output for you? Yeah, mine is:
-I/usr/local/apache/include/apr-0 -I/usr/local/BerkeleyDB.4.1/include
-I/usr/local/include
because I build expat separately and put it in /usr/local.
I'm a little worried about this patch because since you switched it
to only scan away preceding spaces, this only works so long at apr's
include dir is first, but it looks like that's always the case unless
we change apu-config, so OK.
-wsv
On Tuesday, December 3, 2002, at 05:59 AM, Brian Havard wrote:
On Tue, 03 Dec 2002 23:24:46 +1000 (EST), Brian Havard wrote:
On Fri, 29 Nov 2002 12:09:55 -0800, Wilfredo Sánchez wrote:
Yuck OK. $< is used for the ApacheCoreOS2.def, though I suppose
that
only matters for OS/2. I won't touch it.
That should be fine as only gnu make is used to build on OS/2. There's
another problem though that breaks the OS/2 build & I'm not sure what
the
right fix is. What's happening is that exports.c tries to #include
"winconfig.h" which it finds in apr-util/xml/expat/lib/winconfig.h
which
fails as that tries to #include windows.h.
I don't think the expat library headers should be included by
EXPORT_DIRS,
I can't see any reason to force all expat functions into the Apache
core.
On further investigation it appears the culprit is in configure.in
where:
APU_INCLUDEDIR=`$apu_config --includes | sed 's|^.*-I\([[^ ]]*apr[[^
]]*\).*$|\1|'`
which extracts the LAST -I directory when it needs to extract the
first.
My apu-config --include prints:
-I/Apache/httpd-2.0/srclib/apr-util/include
-I/Apache/httpd-2.0/srclib/apr-util/xml/expat/lib
so I get the expat headers which I don't want & I don't get the
apr-util
headers which I do want. This fixes it for me:
Index: configure.in
===
RCS file: /home/cvs/httpd-2.0/configure.in,v
retrieving revision 1.236
diff -u -r1.236 configure.in
--- configure.in 29 Nov 2002 07:34:20 - 1.236
+++ configure.in 3 Dec 2002 12:52:21 -
@@ -100,7 +100,7 @@
APR_ADDTO(LDFLAGS, `$apu_config --ldflags`)
APR_ADDTO(INCLUDES, `$apu_config --includes`)
APU_BINDIR=`$apu_config --bindir`
-APU_INCLUDEDIR=`$apu_config --includes | sed 's|^.*-I\([[^ ]]*apr[[^
]]*\).*$|\1|'`
+APU_INCLUDEDIR=`$apu_config --includes | sed 's|^ *-I\([[^ ]]*apr[[^
]]*\).*$|\1|'`
echo $ac_n "${nl}Configuring PCRE regular expression library ...${nl}"
--
___
___
| Brian Havard | "He is not the messiah!
|
| [EMAIL PROTECTED] | He's a very naughty boy!" - Life
of Brian |
---
---
Tagged the tree...
Hi, I tagged the 2.0 tree just yet as STRIKER_2_0_44_PRE1 in an attempt to get the 2.0.44 show on the road. Please test and point out any problems. This tag builds for me and serves pages at the minimum. I'll run the testsuite tomorrow. Sander PS. I forgot to commit Brian Havards patch before tagging, so the build might still be broken on some platforms.
Re: [PATCH] Allowing extended characters in LDAP authentication...
I'm not very LDAP experienced, but nevertheless I see some problems:
* Brad Nicholes wrote:
> Attached is the first attempt at allowing user ID's with extended characters
> as a valid login ID.
Some browsers cannot use non-ascii characters (they cut as the first
occurence). But that's probably a browser problem and not should not be
subject of discussion.
Next: IIRC should characters that are not ISO-8859-1 be sent as RFC 2047
encoded words. Actually I don't know a browser, that does that, but...
> There are still problems with allowing extended
> characters in passwords
hmm. password data should be opaque 8-bit, shouldn't it?
> This patch adds a new directive "AuthLDAPConvertFromLanguage" to
> mod_auth_ldap that allows the admin to either define a specific language
> when converting the user ID to UTF8 of try to derive the language from the
> header.
*hrm*. That should be splitted. You should not hardcode any assignments
between a language and a charset. For example, the charset of 'de' may be
iso-8859-1 or iso-8859-15 or utf-7 or utf-8 or somewhat (windows-1252...).
You should at least allow the admin to do the assignments himself (similar
to mod_mime's AddLanguage).
> It allows the admin to specify "use-header" which will attempt to
> determine which language to convert from, by parsing the accept-language
> header from the request. Once the user ID has been converted to UTF8,
> authentication is performed against the LDAP directory using the raw
> password as it was recieved in the request. I have considered allowing the
> admin to specify the "to" language since the UTF8 language ID is iconv()
> implementation dependant and may not be the same on all platforms.
Just a Note (may be relevant for the user):
Here seems to be some confusion. UTF-8 is *not* a language, it's a
character encoding, or mime-speaking a charset.
One issue of the patch itself:
+if (convset) {
+inbytes = strlen(user);
+outbytes = (inbytes+1)*2;
+outbuf = apr_pcalloc(r->pool, outbytes);
+
+/* Convert the user name to UTF-8. This is only valid for LDAP v3
*/
+if (convset && (apr_xlate_conv_buffer(convset, user, &inbytes,
outbuf, &outbytes) == APR_SUCCESS)) {
+user = apr_pstrdup(r->pool, outbuf);
+}
+}
outbytes seems to be too small. UTF-8 may require more than the double
space of the original string. (at least 3 times more).
my 0.02 ¤ ([EUR] not present in iso-8859-1 ;-)
nd
--
If God intended people to be naked, they would be born that way.
-- Oscar Wilde
[PATCH] Allowing extended characters in LDAP authentication...
Attached is the first attempt at allowing user ID's with extended characters as a valid login ID. There are still problems with allowing extended characters in passwords because of the encryption methods used when assigning a user password in the directory. So far this appears to work when logging into Novell's eDirectory from a Windows machine but I need to know if it will work one other platforms and with other LDAP libraries. This patch adds a new directive "AuthLDAPConvertFromLanguage" to mod_auth_ldap that allows the admin to either define a specific language when converting the user ID to UTF8 of try to derive the language from the header. It allows the admin to specify "use-header" which will attempt to determine which language to convert from, by parsing the accept-language header from the request. Once the user ID has been converted to UTF8, authentication is performed against the LDAP directory using the raw password as it was recieved in the request. I have considered allowing the admin to specify the "to" language since the UTF8 language ID is iconv() implementation dependant and may not be the same on all platforms. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com mod_auth_ldap.c.patch Description: Binary data
Re: mod_usertrack patch
Jim,
Resubmitting the patch, as you requested.
--
Andrei Zmievski Mail: [EMAIL PROTECTED]
Sr. Front End Software Engineer Web:http://www.fast.no/
Fast Search & Transfer Inc Phone: 781-304-2493
93 Worcester Street Fax:781-304-2410
Wellesley MA 02481-9181, USAMain: 781-304-2400
--- src/modules/standard/mod_usertrack.c.orig Wed Mar 13 16:05:34 2002
+++ src/modules/standard/mod_usertrack.cTue Jul 9 11:10:27 2002
@@ -114,11 +114,18 @@
CT_COOKIE2
} cookie_type_e;
+typedef enum {
+CF_NORMAL,
+CF_COMPACT
+} cookie_format_e;
+
typedef struct {
int enabled;
cookie_type_e style;
+cookie_format_e format;
char *cookie_name;
char *cookie_domain;
+char *prefix_string;
} cookie_dir_rec;
/* Define this to allow post-2000 cookies. Cookies use two-digit dates,
@@ -126,15 +133,18 @@
*/
#define MILLENIAL_COOKIES
-/* Make Cookie: Now we have to generate something that is going to be
- * pretty unique. We can base it on the pid, time, hostip */
-
+/* Default name of the cookie
+ */
#define COOKIE_NAME "Apache"
-static void make_cookie(request_rec *r)
+
+/* Make normal cookie: Try to make something unique based on
+ * pid, time, and hostid, plus the user-configurable prefix.
+ *
+ * This function will make a "verbose" version of the cookie.
+ */
+static char * make_normal_id(char * buffer, int bufsize, request_rec *r)
{
-cookie_log_state *cls = ap_get_module_config(r->server->module_config,
-&usertrack_module);
#if defined(NO_GETTIMEOFDAY) && !defined(NO_TIMES)
clock_t mpe_times;
struct tms mpe_tms;
@@ -146,9 +156,6 @@
struct timezone tz = {0, 0};
#endif /* defined(NETWARE) */
#endif
-/* 1024 == hardcoded constant */
-char cookiebuf[1024];
-char *new_cookie;
const char *rname = ap_get_remote_host(r->connection, r->per_dir_config,
REMOTE_NAME);
cookie_dir_rec *dcfg;
@@ -162,12 +169,13 @@
mpe_times = times(&mpe_tms);
-ap_snprintf(cookiebuf, sizeof(cookiebuf), "%s.%d%ld%ld", rname,
- (int) getpid(),
+ap_snprintf(buffer, bufsize, "%s%s.%d%ld%ld",
+ dcfg->prefix_string, rname, (int) getpid(),
(long) r->request_time, (long) mpe_tms.tms_utime);
#elif defined(NETWARE)
-ap_snprintf(cookiebuf, sizeof(cookiebuf), "%s.%d%ld%ld", rname,
-(int) getpid(), (long) r->request_time, (long) clock());
+ap_snprintf(buffer, bufsize, "%s%s.%d%ld%ld",
+ dcfg->prefix_string, rname, (int) getpid(),
+ (long) r->request_time, (long) clock());
#elif defined(WIN32)
/*
* We lack gettimeofday() and we lack times(). So we'll use a combination
@@ -175,18 +183,100 @@
* was started. It should be relatively unique.
*/
-ap_snprintf(cookiebuf, sizeof(cookiebuf), "%s.%d%ld%ld", rname,
- (int) getpid(),
+ap_snprintf(buffer, bufsize, "%s%s.%d%ld%ld",
+ dcfg->prefix_string, rname, (int) getpid(),
(long) r->request_time, (long) GetTickCount());
#else
gettimeofday(&tv, &tz);
-ap_snprintf(cookiebuf, sizeof(cookiebuf), "%s.%d%ld%d", rname,
- (int) getpid(),
+ap_snprintf(buffer, bufsize, "%s%s.%d%ld%d",
+ dcfg->prefix_string, rname, (int) getpid(),
(long) tv.tv_sec, (int) tv.tv_usec / 1000);
#endif
+return buffer;
+}
+
+
+/* Make normal cookie: Try to make something unique based on
+ * pid, time, and hostid, plus the user-configurable prefix.
+ *
+ * This function will make a "compact" version of the cookie.
+ */
+static char * make_compact_id(char * buffer, int bufsize, request_rec *r)
+{
+#if defined(NO_GETTIMEOFDAY) && !defined(NO_TIMES)
+clock_t mpe_times;
+struct tms mpe_tms;
+#elif !defined(WIN32)
+struct timeval tv;
+#ifdef NETWARE
+time_t tz = 0;
+#else
+struct timezone tz = {0, 0};
+#endif /* defined(NETWARE) */
+#endif
+unsigned long ipaddr = ntohl(r->connection->remote_addr.sin_addr.s_addr);
+cookie_dir_rec *dcfg;
+
+dcfg = ap_get_module_config(r->per_dir_config, &usertrack_module);
+
+#if defined(NO_GETTIMEOFDAY) && !defined(NO_TIMES)
+/* We lack gettimeofday(), so we must use time() to obtain the epoch
+ seconds, and then times() to obtain CPU clock ticks (milliseconds).
+ Combine this together to obtain a hopefully unique cookie ID. */
+
+mpe_times = times(&mpe_tms);
+
+ap_snprintf(buffer, bufsize, "%s%lx%x%lx%lx",
+ dcfg->prefix_string, ipaddr, (int) getpid(),
+(long) r->request_time, (long) mpe_tms.tms_utime);
+#elif defined(NETWARE)
+ap_snprintf(buffer, bufsize, "%s%lx%x%lx%lx",
+ dcfg->prefix_string, ipaddr, (int) getpid(),
+ (long) r->request_time, (long) clock());
+#elif defined(WIN32)
+/*
+ * We lack gettimeofday() an
Re: mod_usertrack patch
Thanks! I'll look over during the weekend! At 9:16 AM -0500 12/6/02, Andrei Zmievski wrote: >Jim, > >Resubmitting the patch, as you requested. > >-- >Andrei Zmievski Mail: [EMAIL PROTECTED] >Sr. Front End Software Engineer Web:http://www.fast.no/ >Fast Search & Transfer Inc Phone: 781-304-2493 >93 Worcester Street Fax:781-304-2410 >Wellesley MA 02481-9181, USAMain: 781-304-2400 > -- === 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
