RE: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
> > I disagree completely. The Windows MPM is fragile, because it is almost > > impossible to read. Bill has been cleaning it up so that multiple > > people can easily modify the code and actually understand what is > > happening. > > > > Knowing how much time Bill has spent reading through that code, and > > trying to solve the underlying problem, I know that he believes he must > > clean the code before he can fix the actual bug. > > > > Ryan > > > > I suggest spending time to learn about code before you begin hacking it > up. I've seen > this exact same pattern repeat itself in Apache 2.0 multiple times. You > and Bill have a > grand vision of 'how things should be', and start making changes. When you > are done, what > once worked is broken and others are left to pick up the pieces and finish > what you > started. Both you guys have done some really good things, don't get me > wrong, but I am > frankly tired of picking up after you guys. > > When I stopped work on the windows MPM, everything worked. I leave it > alone for several > months, you guys come in and start changing things and you f*cked it up. A > bit of testing > after every change would have caught the bug when it was first introduced. > It's not too > much to ask that yuou finish what you start and understand what you are > changing before > you change it. You CANNOT argue you did this with the Windows MPM, because > clearly you did > not. BS I didn't test. I did test. I ran the server for three days after making my changes. In fact, Bill was harping on my to commit the damn patch because I was taking so long to get it in. The problem was that I didn't realize how fragile the damn service stuff was. Nor could I have, because there was no comment explaining what was happening. Add to that, the Windows MPM didn't behave like any other MPM. That means that as people were writing modules for Windows, they were adding hacks to their modules to make up for the way that the MPM did things. That is completely bogus. What I did was to move the Windows MPM back into line with the other MPMs with regard to the pre_mpm hook, so that it was very clearly stated that the pre_mpm hook is called once per Apache instance and the child_init hook is called once per child process. What Bill is doing is cleaning the code so that it looks like other Apache modules and can be followed. Does this mean that he is ripping the module apart and putting it back together? Yes, because that is what is required to understand the damn thing. As for the fact that the Windows MPM was working before we touched it and wasn't working afterwards, I don't believe it. I believe that the changes we made highlighted problems that weren't hitting due to luck before. Do I have proof? How about the fact that all I did was relocate code that was already in the server? I didn't add a single line of code, nor did I remove one. I just moved it from the pre_mpm phase to the child_init phase, which was not all that different at the end of the day. Ryan
Re: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
> > Can we fix the service restart problem before we go making other > changes > > to the MPM? I > > see over the last few days there have been dozens of changes to the > code, > > none of which > > are directed at fixing the service restart problem. All this monkeying > > around with the > > code does is obscure finding what patch introduced the problem. > Bleh... > > I disagree completely. The Windows MPM is fragile, because it is almost > impossible to read. Bill has been cleaning it up so that multiple > people can easily modify the code and actually understand what is > happening. > > Knowing how much time Bill has spent reading through that code, and > trying to solve the underlying problem, I know that he believes he must > clean the code before he can fix the actual bug. > > Ryan > I suggest spending time to learn about code before you begin hacking it up. I've seen this exact same pattern repeat itself in Apache 2.0 multiple times. You and Bill have a grand vision of 'how things should be', and start making changes. When you are done, what once worked is broken and others are left to pick up the pieces and finish what you started. Both you guys have done some really good things, don't get me wrong, but I am frankly tired of picking up after you guys. When I stopped work on the windows MPM, everything worked. I leave it alone for several months, you guys come in and start changing things and you f*cked it up. A bit of testing after every change would have caught the bug when it was first introduced. It's not too much to ask that yuou finish what you start and understand what you are changing before you change it. You CANNOT argue you did this with the Windows MPM, because clearly you did not. Bill
JRE_1 roll.
http://www.apache.org/~jerenkrantz/2.0.32-jre/httpd-2.0.32-JRE-1-alpha.tar.gz It's preliminary. You should be able to grab this version via JRE_1 tag in CVS. Please let me know what you think. While I'd like to wait for Win32 support, others (such as Jeff) think that we shouldn't wait. So, I'll put it up to you all to vote on. I may adjust the JRE_1 tag in CVS as I see fit. This is not a set-in-stone tag - meaning that I may shift it around as needed. Is this tarball beta quality? If so, then I will make this tag 2.0.32. (I don't believe the accept() handling problems stops a beta.) Note: This version will represent itself as .32-dev which I believe is correct since this is *not* a formal release. If you think it is, well, you have lots of problems. -- justin
http://httpd.apache.org/docs/ in french
If I send: Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 with no Accept-Language header, I get a page in french. That isn't right is it? This is what Mozilla generates for me if I go and remove the en-us language from the list of languages.
RE: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
> Can we fix the service restart problem before we go making other changes > to the MPM? I > see over the last few days there have been dozens of changes to the code, > none of which > are directed at fixing the service restart problem. All this monkeying > around with the > code does is obscure finding what patch introduced the problem. Bleh... I disagree completely. The Windows MPM is fragile, because it is almost impossible to read. Bill has been cleaning it up so that multiple people can easily modify the code and actually understand what is happening. Knowing how much time Bill has spent reading through that code, and trying to solve the underlying problem, I know that he believes he must clean the code before he can fix the actual bug. Ryan
Re: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
Can we fix the service restart problem before we go making other changes to the MPM? I
see over the last few days there have been dozens of changes to the code, none of which
are directed at fixing the service restart problem. All this monkeying around with the
code does is obscure finding what patch introduced the problem. Bleh...
Bill
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 08, 2002 2:37 PM
Subject: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
> wrowe 02/02/08 11:37:03
>
> Modified:server/mpm/winnt mpm_winnt.c
> Log:
> Drawing attention to the timing problem; push the wait up so we do about
> nothing until WinNT initializes the app.
>
> Revision ChangesPath
> 1.229 +10 -10httpd-2.0/server/mpm/winnt/mpm_winnt.c
>
> Index: mpm_winnt.c
> ===
> RCS file: /home/cvs/httpd-2.0/server/mpm/winnt/mpm_winnt.c,v
> retrieving revision 1.228
> retrieving revision 1.229
> diff -u -r1.228 -r1.229
> --- mpm_winnt.c 6 Feb 2002 21:09:26 - 1.228
> +++ mpm_winnt.c 8 Feb 2002 19:37:02 - 1.229
> @@ -1585,6 +1585,16 @@
> NULL,
> &si, &pi);
>
> +/* Important:
> + * Give the child process a chance to run before dup'ing the sockets.
> + * We have already set the listening sockets noninheritable, but if
> + * WSADuplicateSocket runs before the child process initializes
> + * the listeners will be inherited anyway.
> + *
> + * XXX: This is badness; needs some mutex interlocking
> + */
> +Sleep(1000);
> +
>/* Undo everything we created for the child only
> */
>CloseHandle(pi.hThread);
> @@ -1605,16 +1615,6 @@
>
>ap_log_error(APLOG_MARK, APLOG_INFO, APR_SUCCESS, ap_server_conf,
> "Parent: Created child process %d", pi.dwProcessId);
> -
> -/* Important:
> - * Give the child process a chance to run before dup'ing the sockets.
> - * We have already set the listening sockets noninheritable, but if
> - * WSADuplicateSocket runs before the child process initializes
> - * the listeners will be inherited anyway.
> - *
> - * XXX: This is badness; needs some mutex interlocking
> - */
> -Sleep(1000);
>
>if (send_handles_to_child(p, *child_exit_event, pi.hProcess, hPipeWrite)) {
>CloseHandle(hPipeWrite);
>
>
>
>
Re: cvs commit: httpd-2.0/server/mpm/winnt mpm_winnt.c
The important thing here is that the process yields to allow the child to initialize.
The
time of the sleep is really not important. The thing that needs to happen is deep in
the
OS, so I am not sure what we would mutex against. Yea, this does suck... it is a bug in
the OS AFAIK cause we shouldn;t have to jump through these hoops.
Bill
> wrowe 02/02/08 11:37:03
>
> Modified:server/mpm/winnt mpm_winnt.c
> Log:
> Drawing attention to the timing problem; push the wait up so we do about
> nothing until WinNT initializes the app.
>
> Revision ChangesPath
> 1.229 +10 -10httpd-2.0/server/mpm/winnt/mpm_winnt.c
>
> Index: mpm_winnt.c
> ===
> RCS file: /home/cvs/httpd-2.0/server/mpm/winnt/mpm_winnt.c,v
> retrieving revision 1.228
> retrieving revision 1.229
> diff -u -r1.228 -r1.229
> --- mpm_winnt.c 6 Feb 2002 21:09:26 - 1.228
> +++ mpm_winnt.c 8 Feb 2002 19:37:02 - 1.229
> @@ -1585,6 +1585,16 @@
> NULL,
> &si, &pi);
>
> +/* Important:
> + * Give the child process a chance to run before dup'ing the sockets.
> + * We have already set the listening sockets noninheritable, but if
> + * WSADuplicateSocket runs before the child process initializes
> + * the listeners will be inherited anyway.
> + *
> + * XXX: This is badness; needs some mutex interlocking
> + */
> +Sleep(1000);
> +
>/* Undo everything we created for the child only
> */
>CloseHandle(pi.hThread);
> @@ -1605,16 +1615,6 @@
>
>ap_log_error(APLOG_MARK, APLOG_INFO, APR_SUCCESS, ap_server_conf,
> "Parent: Created child process %d", pi.dwProcessId);
> -
> -/* Important:
> - * Give the child process a chance to run before dup'ing the sockets.
> - * We have already set the listening sockets noninheritable, but if
> - * WSADuplicateSocket runs before the child process initializes
> - * the listeners will be inherited anyway.
> - *
> - * XXX: This is badness; needs some mutex interlocking
> - */
> -Sleep(1000);
>
>if (send_handles_to_child(p, *child_exit_event, pi.hProcess, hPipeWrite)) {
>CloseHandle(hPipeWrite);
>
>
>
>
Re: recent build breakage in Apache, probably due to apr-util?
On Fri, Feb 08, 2002 at 04:03:19PM -0500, Jeff Trawick wrote: > I'm getting stuff like this on Linux and FreeBSD. > > > htpasswd.o: In function `mkrecord': > > /home/regress/regress/httpd-2.0/support/htpasswd.c:235: undefined > > reference to `apr_sha1_base64' > > collect2: ld returned 1 exit status > > make[2]: *** [htpasswd] Error 1 > > make[1]: *** [all-recursive] Error 1 > > make: *** [all-recursive] Error 1 > > Is anybody else seeing this? My bad. See my recent commits - should be fixed now. =) We're trying to divorce usage of APRVARS in apr-util. -- justin
recent build breakage in Apache, probably due to apr-util?
I'm getting stuff like this on Linux and FreeBSD. > htpasswd.o: In function `mkrecord': > /home/regress/regress/httpd-2.0/support/htpasswd.c:235: undefined > reference to `apr_sha1_base64' > collect2: ld returned 1 exit status > make[2]: *** [htpasswd] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all-recursive] Error 1 Is anybody else seeing this? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
2.0 accept() error handling in Unix
[sorry for the long post, but I think this is important...]
We had three instances recently where daedalus's httpd parent died because of a
fatal error detected in a child. There has been some discussion about what to
do about the remaining children etc, but none about how screwed up our Unix
accept() error handling is which led to the fatal error.
The kernel was periodically running out of fd's. prefork happened to
(indirectly) invoke unixd_accept at an unlucky moment. unixd_accept called apr,
which did the right thing and returned ENFILE. unixd_accept goes thru a rather
unsightly switch statement where none of the cases match. So we hit the
default, which logs the error and returns APR_EGENERAL. Back in prefork,
if (status == APR_EGENERAL) {
clean_child_exit(APEXIT_CHILDFATAL);
yikes! Since Brian B had mentioned the fd problem, I scrambled to get a patch
ready for 2.0.31 so we could survive it.
While I was doing this, I told Jeff about it and he was astonished. He had
recently been beating the crap out of worker on AIX and Solaris with the number
of fd's severely restricted to make sure we didn't do anything foolish, and
hadn't seen such a problem. As it turns out, worker ignores the error and
re-issues the accept(). That's probably better, but if we had a 3rd party
module leaking descriptors for example, it wouldn't help resolve the situation.
1.3 has the same comments mentioning fd leaks so the problem was well known. In
1.3, ENFILE | EMFILE also hit the default (line 4419 in src/main/http_main.c)
but the Unix code then does a clean_child_exit(1). TPF considers the default
fatal.
At first I thought somebody had accidently copied the 1.3 TPF code into 2.0
Unix. But then I had a look at the accept(2) man page on FreeBSD and Linux.
Most of the errno's look like should-not-occur programming errors, so having
default/APR_EGENERAL be a fatal error might be reasonable.
What I think we need is a new APR error category (APR_ENORESOURCE ?
APR_ESICKCHILD ?), similar to APR_EGENERAL, that advises the MPM to cleanly shut
down the child without affecting the parent. This could be set in unixd_accept
for things like EMFILE, ENFILE, ENOBUFS, and ENOMEM, which deal with resource
shortages.
Comments? Better names for the new error category?
Greg
Re: cvs commit: httpd-2.0/include util_ldap.h
I would move it but I have no idea how to. Maybe whoever initially moved the LDAP files could take care of it. Brad Nicholes Senior Software Engineer Novell, Inc., a leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Friday, February 08, 2002 11:48:06 AM >>> On Fri, Feb 08, 2002 at 06:32:51PM -, [EMAIL PROTECTED] wrote: > bnicholes02/02/08 10:32:51 > > Modified:include util_ldap.h > Log: > Updated to use the newer locking API's. This file should probably be moved > to the httpd-ldap with the rest of the auth_ldap stuff. Yeah, it should. -- justin
Re: [PATCH] XHTML/CSS support in mod_autoindex
"William A. Rowe, Jr." wrote: > > From: "Greg Ames" <[EMAIL PROTECTED]> > Sent: Friday, February 08, 2002 9:20 AM > > I am discouraged by the amount of churn in the 2.0 code base with negligible > > benefit to users. > Unfortuantely, some bits like input filtering were 'left unfinished' when the > filtering changes went in. That means we've experienced some pains with that > part of the 2.0 model. I certainly didn't mean to pick on Justin. He has been turning around problems very quickly, and I think he and I agree on the need for a stable release. Actually, the biggest barrier to a stable release at the moment is probably the WinNT MPM. I'm frustrated because I don't have the skills to pitch in and help with it. Greg
Re: cvs commit: httpd-2.0/include util_ldap.h
On Fri, Feb 08, 2002 at 06:32:51PM -, [EMAIL PROTECTED] wrote: > bnicholes02/02/08 10:32:51 > > Modified:include util_ldap.h > Log: > Updated to use the newer locking API's. This file should probably be moved > to the httpd-ldap with the rest of the auth_ldap stuff. Yeah, it should. -- justin
Re: cvs commit: httpd-2.0 STATUS
On Fri, Feb 08, 2002 at 12:53:54PM -0500, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: > How about the configure.in fix for HPUX 11i - would you be bumping the tag > for that file also ??.. If not, then something has to go into the README > file because .31 will not work as-is on a HPUX 11i system.. I'm planning on making .32 be HEAD whenever Win32 is fixed, so this fix will be in. If there is some oddball commit that I think challenges the stability of the tree before then, I won't include it. (That's why I'm maintaining my own tag for now.) -- justin
RE: cvs commit: httpd-2.0 STATUS
How about the configure.in fix for HPUX 11i - would you be bumping the tag for that file also ??.. If not, then something has to go into the README file because .31 will not work as-is on a HPUX 11i system.. Thanks -Madhu -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, February 08, 2002 9:15 AM To: [EMAIL PROTECTED] Subject: cvs commit: httpd-2.0 STATUS jerenkrantz02/02/08 09:15:02 Modified:.STATUS Log: Explain why I'm sitting on .32. Revision ChangesPath 1.490 +10 -1 httpd-2.0/STATUS Index: STATUS === RCS file: /home/cvs/httpd-2.0/STATUS,v retrieving revision 1.489 retrieving revision 1.490 diff -u -r1.489 -r1.490 --- STATUS7 Feb 2002 23:01:47 - 1.489 +++ STATUS8 Feb 2002 17:15:01 - 1.490 @@ -1,5 +1,5 @@ APACHE 2.0 STATUS: -*-text-*- -Last modified at [$Date: 2002/02/07 23:01:47 $] +Last modified at [$Date: 2002/02/08 17:15:01 $] Release: @@ -41,6 +41,15 @@ CURRENT RELEASE NOTES: + +* 32 status: +Justin is waiting for Win32 to become functional. As potential +RM for .32, he considers it a showstopper. Once Win32 is +operational (per EitherBills), .32 will be rolled. If the group +thinks that we could have a good beta without Win32 support, please +note so here. If a majority agree that Win32 is not required for +a beta, Justin will roll .32 ASAP. (And, if you agree with the +fact that Win32 is a showstopper, please note that here too.) * Proposed BETA possibilities 31 + fixes for all resolved problems and call it 32 (instead of HEAD)
Re: rewrite and SSI's broken in httpd20 HEAD
Ian Kallen wrote: > Just thought I'd send in some recently observed behavior... > > I was trying out SSI's on .html files > I have +Includes in Options for htdocs && I tried the example syntax > AddOutputFilter INCLUDES .html > > It does work with .shtml though. > I suggest you look how the .shtml is configured, as I have .html working quite well with CVS head. Options Includes AddOutputFilter INCLUDES .html maybe the '+' is throwing it off.. > Also, I the rnd function in mod_rewrite appears to be broken. Given a > list of alternating choices, it's only ever picking the first one. The > 1.3.x mod_rewrite appeared to truly randomize it's selection. It's doing > this for main and subrequests. > no idea on this one. > cheers, > -Ian > >
Re: rewrite and SSI's broken in httpd20 HEAD
This sort of thing seems to be biting a lot of people. Nobody is aware of the filters section that is now required. In my first pass at getting apache2 and php working, I spent three days before I came across a post made reference to the filters. Perhaps an "UPGRADE" or "README.new-requirements" ... is needed which covers things like this. David Greg Ames wrote: >"Ian Kallen " wrote: > >>Just thought I'd send in some recently observed behavior... >> > >thanks for the feedback. > > >>I was trying out SSI's on .html files >>I have +Includes in Options for htdocs && I tried the example syntax >>AddOutputFilter INCLUDES .html >> > >...and what bad thing happens? SSI tags aren't parsed/expanded I assume? > >we've got the following on daedalus, fwiw: > > >SetOutputFilter INCLUDES > > >>Also, I the rnd function in mod_rewrite appears to be broken. Given a >>list of alternating choices, it's only ever picking the first one. >> > >any idea how long this has been broken on 2.0? forever? > >Greg > smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] XHTML/CSS support in mod_autoindex
From: "Greg Ames" <[EMAIL PROTECTED]> Sent: Friday, February 08, 2002 9:20 AM > yet more evidence that we _really_ need to get a stable Apache 2.0 (as in, > beta/GA with usable binaries) into widespread use. No doubt. I cleaned up 2.0 for XML syntax some great time ago... almost considered a backport, but nahhh... 2.0 will be out soon! Or so I believed. > Otherwise we're going to see more and more pressure for new features in 1.3 > which will eat into our available time. The only developers pressured are those terribly interested in the 1.3 code. I was the only one hacking on Win32 for some time, because others were sure that 2.0 was just around the corner, but I saw a broken build model. Once apxs worked on 1.3, I new I had succeeded. Now I feel little pressure, except from the XP send() corruption bug [in XP but there must be a workaround!] New features :-? Ha. If contributors are busy 'improving' [read, introducing new opportunities for brokenness in] 1.3, then they either have too much time on their hands, insufficient confidence in 2.0 or want to see 1.3 remain a strong viable solution for the near or long term. When you look at how long it took for the world to adopt 1.3 from 1.2, and the fact that development is a matter of scratching our individual itches, then it's not a huge issue. > I am discouraged by the amount of churn in the 2.0 code base with negligible > benefit to users. But massive benefits to module authors. Apache HTTP is as strong as it is, and gets so much devoted attention with corporate blessing precisely because it is an incredible platform to extend. Unfortuantely, some bits like input filtering were 'left unfinished' when the filtering changes went in. That means we've experienced some pains with that part of the 2.0 model. I believe Justin's overhaul substantially corrects those design deficiencies. It's not perfect, perhaps, but getting as close as 2.0 will ever come. The change was painful, but necessary. Bill
Re: rewrite and SSI's broken in httpd20 HEAD
"Ian Kallen " wrote: > > Just thought I'd send in some recently observed behavior... thanks for the feedback. > I was trying out SSI's on .html files > I have +Includes in Options for htdocs && I tried the example syntax > AddOutputFilter INCLUDES .html ...and what bad thing happens? SSI tags aren't parsed/expanded I assume? we've got the following on daedalus, fwiw: SetOutputFilter INCLUDES > Also, I the rnd function in mod_rewrite appears to be broken. Given a > list of alternating choices, it's only ever picking the first one. any idea how long this has been broken on 2.0? forever? Greg
Re: [Patch]: to get the Ldap code building
Ian Holsman <[EMAIL PROTECTED]> writes: > Hi Paul. > I've applied the apr-util config change. > I dont have access (never tried) to httpd-ldap so you'll > need to pester the list again for these changes. AFAICT, anybody that can commit to httpd can commit to httpd-ldap. Go for it, Paul. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
rewrite and SSI's broken in httpd20 HEAD
Just thought I'd send in some recently observed behavior... I was trying out SSI's on .html files I have +Includes in Options for htdocs && I tried the example syntax AddOutputFilter INCLUDES .html It does work with .shtml though. Also, I the rnd function in mod_rewrite appears to be broken. Given a list of alternating choices, it's only ever picking the first one. The 1.3.x mod_rewrite appeared to truly randomize it's selection. It's doing this for main and subrequests. cheers, -Ian -- Ian Kallen <[EMAIL PROTECTED]> | AIM/yahoo: iankallen
Re: [PATCH] enable static support binaries at build-time
Aaron Bannert <[EMAIL PROTECTED]> writes: > On Thu, Feb 07, 2002 at 02:12:42PM -0800, Justin Erenkrantz wrote: > > On Thu, Feb 07, 2002 at 01:23:08PM -0800, Aaron Bannert wrote: > > > This does _not_ add support for a static httpd, since that issue is > > > not yet decided, but it should solve 7 of the 8 binaries that Ken was > > > worried about. The "should httpd also be static" discussion can happen > > > independently of this patch. > > > > Personally, I agree that the httpd *can* be static, but not that > > it *should* be static. Can we just go ahead and add that while we're > > at it? IMHO, the real discussion is what is the default. -- justin > > I'm not so sure that it can be static on all platforms in the first place. > My main concern is a missing symbol required by a module that isn't > available in httpd or properly exported, which causes a runtime failure > at some unknown time *after* the server appears to successfully start; > but this could just be paranoia on my part. > > I'd also rather not allow this discussion to block the above patch, > since I think we'd all agree that it is acceptable. Damn straight. Commit already :) Like Justin, I think it is goodness to have a configure option like --static-httpd. Obviously such a thought has no bearing on the patch you posted. I have the *feeling* that it is not good for binbuild.sh to use such an option (--static-httpd) but I don't have a technical argument behind that. Do we all violently agree? -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Don't forget the testers
It seems to me that somehow we keep forgetting to let the
volunteer testers ({stable,current}[EMAIL PROTECTED])
know about our progress and that we're preparing to release..
BTW, those lists should probably get moved to @httpd.apache.org. :-)
--
#kenP-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
Re: [PATCH] XHTML/CSS support in mod_autoindex
tom stuart wrote: > apache 2.0's > mod_autoindex provides a remedy for this problem; however, 1.3 is the > current stable version of apache, and it cannot produce valid XHTML > directory listings. yet more evidence that we _really_ need to get a stable Apache 2.0 (as in, beta/GA with usable binaries) into widespread use. Otherwise we're going to see more and more pressure for new features in 1.3 which will eat into our available time. I am discouraged by the amount of churn in the 2.0 code base with negligible benefit to users. Greg
[PATCH] XHTML/CSS support in mod_autoindex
[filed a week ago in the bug database (PR#9693)]
>Description:
XML adoption is becoming increasingly widespread, and more and more
people want to build web sites that validate as XHTML. apache 2.0's
mod_autoindex provides a remedy for this problem; however, 1.3 is the
current stable version of apache, and it cannot produce valid XHTML
directory listings.
>Fix:
(patches can be downloaded from http://obsess.com/files/apache/)
below are patches against the current apache-1.3 and htdocs-1.3 cvs
modules to provide an implementation of and documentation for an
EmitXHTML index option and a StyleName configuration directive. this
provides a huge opportunity for visual formatting of directory listings,
as well as making sure that directory indexes validate along with the
rest of a web site and are simple for clients to automatically parse.
the intent was to have as little impact on mod_autoindex as possible,
leaving its behaviour entirely unchanged unless the new functionality is
explicitly invoked. code style has therefore been kept consistent with
existing mod_autoindex code.
unfortunately this feature involved touching httpd.h to add a define for
DOCTYPE_XHTML_1_0S (plus DOCTYPE_XHTML_1_0T and DOCTYPE_XHTML_1_0F while
we're in there) and http_core.c to make the tags XHTML
compliant (just changing them from upper to lower case). i found it hard
to imagine the latter having any compatibility impact but it can be left
out if necessary; full XHTML compliance could then still be achieved by
turning ServerSignature off.
see additional ISO 8601 and HEADER/README comments and additional
patches further down.
Index: apache-1.3/src/include/httpd.h
===
RCS file: /home/cvspublic/apache-1.3/src/include/httpd.h,v
retrieving revision 1.352
diff -u -r1.352 httpd.h
--- apache-1.3/src/include/httpd.h 21 Jan 2002 19:29:37 - 1.352
+++ apache-1.3/src/include/httpd.h 4 Feb 2002 13:06:21 -
@@ -614,6 +614,15 @@
#define DOCTYPE_HTML_4_0F "http://www.w3.org/TR/REC-html40/frameset.dtd\";>\n"
+#define DOCTYPE_XHTML_1_0S "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\";>\n"
+#define DOCTYPE_XHTML_1_0T "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\";>\n"
+#define DOCTYPE_XHTML_1_0F "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd\";>\n"
/* Just in case your linefeed isn't the one the other end is expecting. */
#ifndef CHARSET_EBCDIC
Index: apache-1.3/src/main/http_core.c
===
RCS file: /home/cvspublic/apache-1.3/src/main/http_core.c,v
retrieving revision 1.303
diff -u -r1.303 http_core.c
--- apache-1.3/src/main/http_core.c 16 Jan 2002 21:34:32 - 1.303
+++ apache-1.3/src/main/http_core.c 4 Feb 2002 13:06:23 -
@@ -2726,15 +2726,15 @@
ap_snprintf(sport, sizeof sport, "%u", (unsigned) ap_get_server_port(r));
if (conf->server_signature == srv_sig_withmail) {
- return ap_pstrcat(r->pool, prefix, "" SERVER_BASEVERSION
- " Server at mailto:";,
+ return ap_pstrcat(r->pool, prefix, "" SERVER_BASEVERSION
+ " Server at mailto:";,
r->server->server_admin, "\">",
- ap_get_server_name(r), " Port ", sport,
- "\n", NULL);
+ ap_get_server_name(r), " Port ", sport,
+ "\n", NULL);
}
-return ap_pstrcat(r->pool, prefix, "" SERVER_BASEVERSION
+return ap_pstrcat(r->pool, prefix, "" SERVER_BASEVERSION
" Server at ", ap_get_server_name(r), " Port ", sport,
- "\n", NULL);
+ "\n", NULL);
}
/*
Index: apache-1.3/src/modules/standard/mod_autoindex.c
===
RCS file: /home/cvspublic/apache-1.3/src/modules/standard/mod_autoindex.c,v
retrieving revision 1.121
diff -u -r1.121 mod_autoindex.c
--- apache-1.3/src/modules/standard/mod_autoindex.c 17 Nov 2001 03:27:09 -
1.121
+++ apache-1.3/src/modules/standard/mod_autoindex.c 4 Feb 2002 13:06:23 -
@@ -98,6 +98,7 @@
#define NO_OPTIONS 256
#define FOLDERS_FIRST 512
#define TRACK_MODIFIED 1024
+#define EMIT_XHTML 2048
#define K_PAD 1
#define K_NOPAD 0
@@ -162,6 +163,7 @@
array_header *ign_list;
array_header *hdr_list;
array_header *rdme_list;
+array_header *css_list;
} autoindex_config_rec;
@@ -195,11 +197,37 @@
* We include the DOCTYPE because we may be using features therefrom (i.e.,
* HEIGHT and WIDTH attributes on the icons if we're FancyIndexing).
*/
-static void emit_preamble(request_rec *r, char *title)
+static void emit_preamble(request_rec *r, char *title, char *css_fname,
+ int emit_xhtml)
{
-ap_rvputs(r, DOCTYPE_HTML_3_2,
- "\n \n Index of ", title,
- "\n \n \n", NULL);
+request_
