Re: Tagging .31 soon
> From: "Greg Ames" <[EMAIL PROTECTED]> > Sent: Wednesday, January 23, 2002 12:40 PM > > > Ian Holsman wrote: > > > > > > probably tomorrow if no major problems/objections occur. > > > > I don't remember seeing a fix for the recursive subrequest loops involving > > mod_negotiation. Did I miss it? Ok... this is the last priority issue I've put on my own plate prior to another beta release. The other three issues seem closed. I'll fight on tommorow. Hoping you are around, Greg, if I come up with any experimental solutions to try. Bill
Re: Current CVS on Win32
> From: "Sebastian Bergmann" <[EMAIL PROTECTED]> > Sent: Wednesday, January 23, 2002 8:07 AM > > > 'lo there, > > > > just wanted to let you know that the current CVS version of Apache does > > not start on Win32. It does not crash, but exits after invoking it > > through Apache.exe from commandline. I'll get a Windows error message > > that the service could not be started but provided no error message > > when trying to start it with 'net start apache2'. Apache on Win32 should now thoroughly work WRT startup and the scoreboard, even if you omit the ScoreboardFile directive. [I'm uncertain if the mod_rewrite lock breakage is resolved or not.]
Re: changing dev.apache.org (was Re: cvs commit: apache-devsite
Done. :) Brian On Thu, 24 Jan 2002, Jim Jagielski wrote: > +1 > > Brian Behlendorf wrote: > > > > On Thu, 24 Jan 2002, Ian Holsman wrote: > > > why don't we change the virtual host entry for dev.apache.org to > > > redirect EVERYTHING to httpd://httpd.apache.org/dev/ > > > > > >ServerName dev > > > > > > RewriteEngine on > > > RewriteRule ^/(.*) http://httpd.apache.org/dev/ [R] > > > > > > > > > > I'd be happy to do that, just say the word. > > > > Brian > > > > > > > > >
Re: changing dev.apache.org (was Re: cvs commit: apache-devsite
+1 (which makes 3) Brian, blow it away ;-) Justin Erenkrantz wrote: > +1 (me too). -- justin > > On Thu, Jan 24, 2002 at 10:28:40PM -0500, Jim Jagielski wrote: > >>+1 >> >>Brian Behlendorf wrote: >> >>>On Thu, 24 Jan 2002, Ian Holsman wrote: >>> why don't we change the virtual host entry for dev.apache.org to redirect EVERYTHING to httpd://httpd.apache.org/dev/ ServerName dev RewriteEngine on RewriteRule ^/(.*) http://httpd.apache.org/dev/ [R] >>>I'd be happy to do that, just say the word. >>> >>> Brian >>> >
Re: the announcement
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]> Sent: Thursday, January 24, 2002 10:53 PM > I ended up with this somewhat serious discrepancy. Clearly, when > you or Bill ran it all through expand.pl, the .html.html files simply > bombed out. [I ran expand.pl as well, with no hassle.] Thoughts? My thought on this is pretty simple, these were generated files, fix and just re-roll. Same tag. These files aren't stored in CVS in this format, so it doesn't harm anything. Bill > diff -r -u3 apache_1.3.23.tar.gz\htdocs\manual\keepalive.html.html >apache_1.3.23.zip\htdocs\manual\keepalive.html.html > --- apache_1.3.23.tar.gz\htdocs\manual\keepalive.html.html Wed Jan 23 06:01:11 2002 > +++ apache_1.3.23.zip\htdocs\manual\keepalive.html.html Thu Jan 24 20:23:31 2002 > @@ -13,7 +13,13 @@ > >vlink="#80" alink="#FF"> > - > + > + > + > + Apache HTTP Server > + > + > +
Re: changing dev.apache.org (was Re: cvs commit: apache-devsite
+1 (me too). -- justin On Thu, Jan 24, 2002 at 10:28:40PM -0500, Jim Jagielski wrote: > +1 > > Brian Behlendorf wrote: > > > > On Thu, 24 Jan 2002, Ian Holsman wrote: > > > why don't we change the virtual host entry for dev.apache.org to > > > redirect EVERYTHING to httpd://httpd.apache.org/dev/ > > > > > >ServerName dev > > > > > > RewriteEngine on > > > RewriteRule ^/(.*) http://httpd.apache.org/dev/ [R] > > > > > > > > > > I'd be happy to do that, just say the word. > > > > Brian
Re: the announcement
From: "Jim Jagielski" <[EMAIL PROTECTED]> Sent: Thursday, January 24, 2002 9:32 PM > will be going out tonite... I see one serious problem [yup - being too thorough again.] I generally construct win32 both ways, through lineends.pl which I wrote to fix .tar.gz's and other beasts, and through cvs co. I ended up with this somewhat serious discrepancy. Clearly, when you or Bill ran it all through expand.pl, the .html.html files simply bombed out. [I ran expand.pl as well, with no hassle.] Thoughts? diff -r -u3 apache_1.3.23.tar.gz\htdocs\manual\keepalive.html.html apache_1.3.23.zip\htdocs\manual\keepalive.html.html --- apache_1.3.23.tar.gz\htdocs\manual\keepalive.html.html Wed Jan 23 06:01:11 2002 +++ apache_1.3.23.zip\htdocs\manual\keepalive.html.html Thu Jan 24 20:23:31 2002 @@ -13,7 +13,13 @@ - + + + + Apache HTTP Server + + + Apache Keep-Alive Support @@ -89,7 +95,11 @@ not use the Keep-Alive protocol. While this should be completely transparent to the end user, it is something the web-master may want to keep in mind. - + + +Apache HTTP Server + + diff -r -u3 apache_1.3.23.tar.gz\htdocs\manual\mod\directive-dict.html.html apache_1.3.23.zip\htdocs\manual\mod\directive-dict.html.html --- apache_1.3.23.tar.gz\htdocs\manual\mod\directive-dict.html.html Wed Jan 23 06:01:17 2002 +++ apache_1.3.23.zip\htdocs\manual\mod\directive-dict.html.html Thu Jan 24 20:23:32 +2002 @@ -14,7 +14,12 @@ - + + + + Apache HTTP Server Version 1.3 + + Terms Used to Describe Apache Directives @@ -300,7 +305,12 @@ the NCSA HTTPd server, any inconsistencies in behavior between the two should also be mentioned. Otherwise, this attribute should say "No compatibility issues." - + + +Apache HTTP Server Version 1.3 + + + diff -r -u3 apache_1.3.23.tar.gz\htdocs\manual\programs\index.html.html apache_1.3.23.zip\htdocs\manual\programs\index.html.html --- apache_1.3.23.tar.gz\htdocs\manual\programs\index.html.html Wed Jan 23 06:01:26 2002 +++ apache_1.3.23.zip\htdocs\manual\programs\index.html.html Thu Jan 24 20:23:32 2002 @@ -13,7 +13,12 @@ - + + + + Apache HTTP Server Version 1.3 + + Server and Supporting Programs @@ -67,7 +72,13 @@ Other Programs - + + +Apache HTTP Server Version 1.3 + + + + diff -r -u3 apache_1.3.23.tar.gz\htdocs\manual\vhosts\index.html.html apache_1.3.23.zip\htdocs\manual\vhosts\index.html.html --- apache_1.3.23.tar.gz\htdocs\manual\vhosts\index.html.html Wed Jan 23 06:01:27 2002 +++ apache_1.3.23.zip\htdocs\manual\vhosts\index.html.html Thu Jan 24 20:23:32 2002 @@ -13,7 +13,12 @@ - + + + + Apache HTTP Server Version 1.3 + + Apache Virtual Host documentation @@ -79,7 +84,12 @@ will dump out a description of how Apache parsed the configuration file. Careful examination of the IP addresses and server names may help uncover configuration mistakes. - + + +Apache HTTP Server Version 1.3 + + + diff -r -u3 apache_1.3.23.tar.gz\htdocs\manual\vhosts\name-based.html.html apache_1.3.23.zip\htdocs\manual\vhosts\name-based.html.html --- apache_1.3.23.tar.gz\htdocs\manual\vhosts\name-based.html.html Wed Jan 23 06:01:27 2002 +++ apache_1.3.23.zip\htdocs\manual\vhosts\name-based.html.html Thu Jan 24 20:23:33 +2002 @@ -11,7 +11,12 @@ - + + + + Apache HTTP Server Version 1.3 + + Name-based Virtual Host Support @@ -229,7 +234,12 @@ See also: ServerPath configuration example - + + +Apache HTTP Server Version 1.3 + + +
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
From: "Greg Ames" <[EMAIL PROTECTED]> Sent: Thursday, January 24, 2002 11:01 AM > Greg Ames wrote: > > > I don't remember seeing a fix for the recursive subrequest loops involving > > mod_negotiation. > > The backtrace I posted showed that apr_filepath_merge's addpath arg was > "builds/tomcat/release/v3.1/v3.1.1/v3.1.1/v3.1.1/..." This comes from > r->filename in ap_directory_walk. That seems odd in a few ways, beside the ever > growing bogus path. > > * why would we try to negotiate at all, when the only candidates are > directories, not files? Ack - that's twisted. > * it looks like we might be triggering some 1.3 negotiation behavior, where any > extention under the sun is a match. We use MultiviewsMatch Handlers, so .asis > and .cgi extentions do not need to be specified in the URI. Of course. This is as-desired, no? > * why do we see /builds/tomcat/ rather than /builds/jakarta-tomcat/ in > r->filename? I would think the redirect would happen early, and subsequent > filenames would contain the new path. Probably not important, because we got > the same loop when jakarta-tomcat was part of the original URI. Remember one bit, when I modified mod_dir, it now acts immediately using the fast_internal_redirect logic instead of the old logic in some cases. I'm certain we are hitting just such a case, and the two of them, together, have a serious issue. I'm sorry I've had a 50 hour week [yes - not yet Friday even] so I just haven't been able to look at this as promised. But I'm certain there is something 'interesting' in the points you made - a redirect to something absent, etc, that will help point us at the right direction; good catch! Bill
the announcement
will be going out tonite... -- === 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"
Re: changing dev.apache.org (was Re: cvs commit: apache-devsite
+1 Brian Behlendorf wrote: > > On Thu, 24 Jan 2002, Ian Holsman wrote: > > why don't we change the virtual host entry for dev.apache.org to > > redirect EVERYTHING to httpd://httpd.apache.org/dev/ > > > >ServerName dev > > > > RewriteEngine on > > RewriteRule ^/(.*) http://httpd.apache.org/dev/ [R] > > > > > > I'd be happy to do that, just say the word. > > Brian > > > -- === 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"
Re: cvs commit: httpd-2.0 STATUS
On Fri, Jan 25, 2002 at 02:23:37AM -, [EMAIL PROTECTED] wrote: > jerenkrantz02/01/24 18:23:37 > > Modified:.STATUS > Log: > showstoppers--; > > APR knows when to let go of those pesty kids now. If you were getting bit by the APR pipe leakage (either in mod_cgid in httpd-2.0 or svn_run_io_cmd in SVN), please try again. One of my servers filled up its / partition with a 10GB error_log complaining that mod_cgid was out of file descriptors. With my dup2 change to APR in proc.c, mod_cgid doesn't seem to leak fds per request. If you still see it, please let me know. But, I think it's fixed now. -- justin
Re: cvs commit: httpd-2.0/include http_protocol.h
On Thu, Jan 24, 2002 at 11:59:51PM -, [EMAIL PROTECTED] wrote: > jerenkrantz02/01/24 15:59:51 > > Modified:.CHANGES >server protocol.c >include http_protocol.h > Log: > Rewrite ap_rgetline to remove the need to have an "internal" brigade stored > in the core_module structure by using the AP_MODE_SPECULATIVE filter mode > to determine if MIME-continuation should occur. > > Notes: > - ap_rgetline has a new prototype. > - ap_rgetline returns APR_ENOSPC when we are out of buffer space. > > All direct callers of ap_rgetline are now adjusted to handle this new API. > ap_getline will mimic the old API for now. Please let me know if anything breaks. I tried to test as best as I could. I'm especially curious to see what happens on EBCDIC platforms. I suspect it *might* be broken, but I'm not sure. -- justin
Re: cvs commit: httpd-2.0/modules/dav/fs repos.c
On Thu, Jan 24, 2002 at 06:00:04PM -0600, William A. Rowe, Jr. wrote: >... > You are most welcome... I'll walk away for a bit again, > and let you round these out :) Urf... actually that last change of yours for the executable flag required a full-on power grinder :-( (fixes checked in now) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/modules/dav/fs repos.c
From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Thursday, January 24, 2002 5:00 PM
> On Thu, Jan 24, 2002 at 03:23:58PM -, [EMAIL PROTECTED] wrote:
> > wrowe 02/01/24 07:23:58
> >
> > Modified:modules/dav/fs repos.c
> > Log:
> > Cause dav_fs_get_parent_resource to fail if the file path is entirely
> > invalid or incomplete, or if it is root [determined by the platform's
> > apr implemention]. Identified by Greg Stein.
>
> Well, it was also intended to mean "root URI path". There is no parent for
> http://example.com/. Similarly, there is no parent for
> http://example.com/foo/bar/ when that Location maps to C:/
>
>
> >...
> > --- repos.c 23 Jan 2002 20:55:10 - 1.58
> > +++ repos.c 24 Jan 2002 15:23:58 - 1.59
> > @@ -735,10 +735,18 @@
> >dav_resource *parent_resource;
> >apr_status_t rv;
> >char *dirpath;
> > +char *testroot;
> > +char *testpath;
> >
> > -/* If given resource is root, then there is no parent */
> > -if (strcmp(resource->uri, "/") == 0 ||
> > -ap_os_is_path_absolute(ctx->pool, ctx->pathname)) {
>
> That first strcmp() is needed for the URI part of the test.
>
> I'll fix it.
>
> Thanks for the patches, Bill!
You are most welcome... I'll walk away for a bit again,
and let you round these out :)
Bill
Re: changing dev.apache.org (was Re: cvs commit: apache-devsitehow-to-release.html)
On Thu, 24 Jan 2002, Ian Holsman wrote: > why don't we change the virtual host entry for dev.apache.org to > redirect EVERYTHING to httpd://httpd.apache.org/dev/ > >ServerName dev > > RewriteEngine on > RewriteRule ^/(.*) http://httpd.apache.org/dev/ [R] > > I'd be happy to do that, just say the word. Brian
Re: cvs commit: httpd-2.0/modules/dav/fs repos.c
On Thu, Jan 24, 2002 at 03:23:58PM -, [EMAIL PROTECTED] wrote:
> wrowe 02/01/24 07:23:58
>
> Modified:modules/dav/fs repos.c
> Log:
> Cause dav_fs_get_parent_resource to fail if the file path is entirely
> invalid or incomplete, or if it is root [determined by the platform's
> apr implemention]. Identified by Greg Stein.
Well, it was also intended to mean "root URI path". There is no parent for
http://example.com/. Similarly, there is no parent for
http://example.com/foo/bar/ when that Location maps to C:/
(yes, the latter case has a parent, but mod_dav_fs and Apache aren't quite
sophisticated enough to figure it out)
>...
> --- repos.c 23 Jan 2002 20:55:10 - 1.58
> +++ repos.c 24 Jan 2002 15:23:58 - 1.59
> @@ -735,10 +735,18 @@
>dav_resource *parent_resource;
>apr_status_t rv;
>char *dirpath;
> +char *testroot;
> +char *testpath;
>
> -/* If given resource is root, then there is no parent */
> -if (strcmp(resource->uri, "/") == 0 ||
> -ap_os_is_path_absolute(ctx->pool, ctx->pathname)) {
That first strcmp() is needed for the URI part of the test.
I'll fix it.
Thanks for the patches, Bill!
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/modules/dav/fs lock.c repos.c
On Thu, Jan 24, 2002 at 08:42:05AM -0600, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <[EMAIL PROTECTED]>
> Sent: Thursday, January 24, 2002 4:09 AM
>...
> > Looking at the usage of 'finfo', this could be APR_FINFO_SIZE
>
> Yup, I had limited time ... so I simply made it work. That patch can definately
> be optimized based on the context of the apr_file_info_get and lstat changes!
Understood. I just happened to see it during the code review :-)
>...
> > > -#ifndef WIN32
> > >{
> > >dav_lock_discovery *ld;
> > >dav_lock_indirect *id;
> > > @@ -1071,7 +1078,6 @@
> > >return err;
> > >}
> > >}
> > > -#endif
> >
> > Hmm. Debatable change. It could end up removing a lock record, then putting
> > it right back. I don't think it is a real problem, tho.
>
> Goal 1 of APR, module code doesn't use #if PLAT fooness, or it will discover
> itself borked in future ports :) Is there a trivial patch to discover [or cache]
> the fact that the platform won't support the feature?
The WIN32 block was based on "win32 doesn't have inode/dev". When a platform
doesn't have that, then all locks are stored using pathnames. If a platform
*does* have inode/dev, then it uses them for most of the locks. However, you
can have a lock on a file that doesn't exist, so there is no inode/dev, so
those locks use the pathname. When an inode/dev arrives, then the above
#ifndef/#endif code is needed to convert a lock from the pathname style to
the inode/dev style.
So... the test is whether you have an inode/dev for a given file.
The above code removes the pathname-based lock, then computes a new key, and
saves the lock. If the platform does not support inode/dev, then the key
recomputation will come up with the same thing. No biggy. But if the
platform *does* support it, then it does the right thing.
[ as I said in the post: a bit of extra work, but it should still function
properly ]
>...
> Reviewing ... yup. This needs an apr_filepath_root() call, and test if we
> have any remaining path info [if so, it isn't the root.] apr_filepath_root
> slurps off the leading '/' in unix, the leading dir in win32/os2, and
> //mach/share on win32 (os2?) and mach:/share on netware.
>
> Correct? I'll fix.
Sounds good. One comment coming up on that patch, tho.
>...
> > If the device doesn't exist or doesn't match, then it just does a copy.
>
> My question was; can this be a tristate (can_rename, try_rename, must_copy)
> for platforms that can't tell us in advance about .dev? It's preferable
> to fail-over in the try_rename case, I would expect.
That would certainly be possible. However, once you introduce the failover,
then you wouldn't ever have can_rename. Thus, your logic would be:
* have device, if they match: try_rename
* have device, if they don't match: must_copy
* no device: try_rename
The complication arises in try_rename: how do you detect a failure due to
cross-device move/rename, as opposed to a real failure?
Maybe you just ignore most failures on a rename, and try the copy? Only give
a "real" failure if the copy fails, too?
>...
> > And one more to put back.
>
> So these work on OS2/Netware today? If so, I agree. If not, dav is broken,
> and adding a list of more platforms is the wrong solution, IMHO.
Oh, probably not :-) But we went from "working on Unix and Win32" to
"working on Unix". Thus, my complaint...
[ "working" in the sense tha the property was (correctly) present on unix,
and (correctly) absent on win32. ]
>...
> > *dirpath_p is not set in the 'else' branch.
>
> In the else case, the path is either APR_EBADPATH [meaning *dirpath_p
> isn't split into file + path, so *dirpath_p is returned to the caller
> as-given]
*dirpath_p was always set in the prior code, so "as-given" is meaningless.
> or APR_EINCOMPLETE [again *dirpath_p is returned as-was]
same.
> since the some had been too agressive in splitting off names (there
> is no meaning to //server without a successive /share/ element, together
> they form the root path).
Understood (the prior code was bad).
Just pointing out that the new code doesn't have the same invariant. That is
bad.
Ideally, the code should return an error. I can fix that...
>...
> So *dirpath_p can/should retain it's identity if ap_make_dirstr_parent really
> never had a 'child' object?
We should produce an error. That function *must* be supplied a filename. The
function says " file in directory." We then do some other work
in the directory.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
changing dev.apache.org (was Re: cvs commit: apache-devsite how-to-release.html)
Jim Jagielski wrote: > Justin Erenkrantz wrote: > >>On Thu, Jan 24, 2002 at 04:16:50PM -, [EMAIL PROTECTED] wrote: >> >>>jim 02/01/24 08:16:50 >>> >>> Modified:.how-to-release.html >>> Log: >>> Some changes due to reorg >>> >>All of these docs are in httpd-site/xdocs/dev. >> >>I believe that version is up-to-date, but please check. >> >>apache-devsite and dev.apache.org are no longer used. -- justin >> >> > > I just wanted to sync up dev.apache.org, which still exists, just in > case. I'm still updating some of the other files... why don't we change the virtual host entry for dev.apache.org to redirect EVERYTHING to httpd://httpd.apache.org/dev/ ServerName dev RewriteEngine on RewriteRule ^/(.*) http://httpd.apache.org/dev/ [R] ???
info msg at startup if canonical port != a listen?
Typical newbie* problem: Listen 8080 no ServerName or ServerName doesn't specify port 8080 With this config, certain self-referential URLs will fail. Is there some way we can issue an info or warn message at startup if we can tell that self-referential URLs are broken? It is probably not possible to diagnose every possible problem (vhosts), but we could avoid some newbie problems. As far as the default conf: comment says "This can often be determined automatically..." that is incorrect as I understand it (unless the real fix is for the default ServerName to have a port that corresponds to some actual Listen statement; if there is more than one then we can't guess well, but maybe we should pick one and issue a message to that effect) By default we have Listen @@Port@@ Shouldn't the commented-out ServerName have @@Port@@ for the port instead of 80? Also, isn't it appropriate to have comments near the Listen statement to indicate that the port may need to be specified via ServerName as well? *fancy name for Jeff when he isn't very careful -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/server scoreboard.c
From: "Aaron Bannert" <[EMAIL PROTECTED]> Sent: Thursday, January 24, 2002 12:09 PM > I had thought that on platforms that supported it, we would prefer > the anonymous shared memory (as we were using before) to a name-based > solution, for whatever reason (performance and/or security perhaps). I > have no empirical evidence claiming either to be superior, I just wanted > to leave the underlying scoreboard mechanism as close as possible to > what it was before the recent shmem changes. > > How about this: > > - if the user specifies a ScoreboardFile then we use name-based memory > with that file, and failures are absolute. > - if none is specified, we get to chose -- right now i see this as > - platforms with fork try anonymous* then fall back to name-based > - other platforms do name-based > (for name-based we have to come up with a name like what we have now. > If it happens to be on an NFS partition, then it may fail, but we'll > have made notice of this in the docs and the config comments.) Actually, win32 will do anonymous in just a few minutes more, if no file backing name is given. Please proceed with a patch to correct, as you've described. Bill
Re: [HEAD] --with-mpm=worker under FreeBSD 4.5 does nothing?
On Thu, Jan 24, 2002 at 09:19:45AM -0400, Marc G. Fournier wrote: > On Wed, 23 Jan 2002, Aaron Bannert wrote: > > > > Now, does apache2 *require* shared memory, or can I set all of the above > > > to zero, and it will work around the limitation? Setting them all to zero will fail on Unix. > > If you wish to run apache with multiple processes, then shared memory > > is necessary. > > How did Apache1 deal with this? It ran multiple processes, but had no > shared memory requirement ... I'm sorry, I should have been more clear. By "shared memory" I also included things like mmap()ing a common file, which from my perspective is just another type of shared memory. Those types are: APR_USE_SHMEM_MMAP_TMP (file-based) APR_USE_SHMEM_MMAP_SHM (file-based) APR_USE_SHMEM_MMAP_ZERO (anonymous) APR_USE_SHMEM_MMAP_ANON (anonymous) The SYSV types that you have disabled in your chroot jail are probably these two: APR_USE_SHMEM_SHMGET_ANON APR_USE_SHMEM_SHMGET -aaron
Re: cvs commit: httpd-2.0/server scoreboard.c
On Thu, Jan 24, 2002 at 10:09:50AM -0800, Aaron Bannert wrote: > How about this: > > - if the user specifies a ScoreboardFile then we use name-based memory > with that file, and failures are absolute. > - if none is specified, we get to chose -- right now i see this as > - platforms with fork try anonymous* then fall back to name-based > - other platforms do name-based > (for name-based we have to come up with a name like what we have now. > If it happens to be on an NFS partition, then it may fail, but we'll > have made notice of this in the docs and the config comments.) > > (*anonymous shmem should not reattach in the child) Oh yeah, and this is how it is now, except for the first point (we don't let the ScoreboardFile override our preference, but we should) and the minor bug that apache needs to remove the scoreboard file before trying the shmem. -aaron
Re: cvs commit: httpd-2.0/server scoreboard.c
On Thu, Jan 24, 2002 at 08:29:01AM -0800, Justin Erenkrantz wrote: > On Thu, Jan 24, 2002 at 11:23:39AM -0500, Bill Stoddard wrote: > > The issue is not whether we need a "file" backing the scoreboard. On Unix, you >make the > > scoreboard use a file when the OS does not support shared memory. > > I think Aaron pointed out in a recent exchange with a FreeBSD user > that we don't support any OS without shared memory (FreeBSD disables > shmem in a jail). IIRC, file-backed scoreboards are no longer > supported in 2.0 (i.e. no use of shmem at all). Some OSes require > a path to "setup" the scoreboard via shmem. FWIW, this seems > identical to your issue in Win32. > > (I could be wrong, but that is my interpretation.) -- justin Actually, one of the "name-based shared memory" types on Unix is an mmap()ed file. If that is how we were doing file-backed shared memory before then it's still in there. The bigger point here is that we don't make a distinction between file-backed and non-file-backed shared memory anymore. The only distinction we have is anonymous and name-based. All name-based shmem types rely on a file in the filesystem, either to rendezvous two unrelated processes or to back (store) the actual shared data. I had thought that on platforms that supported it, we would prefer the anonymous shared memory (as we were using before) to a name-based solution, for whatever reason (performance and/or security perhaps). I have no empirical evidence claiming either to be superior, I just wanted to leave the underlying scoreboard mechanism as close as possible to what it was before the recent shmem changes. How about this: - if the user specifies a ScoreboardFile then we use name-based memory with that file, and failures are absolute. - if none is specified, we get to chose -- right now i see this as - platforms with fork try anonymous* then fall back to name-based - other platforms do name-based (for name-based we have to come up with a name like what we have now. If it happens to be on an NFS partition, then it may fail, but we'll have made notice of this in the docs and the config comments.) (*anonymous shmem should not reattach in the child) -aaron
Re: cvs commit: httpd-2.0/server scoreboard.c
On Thu, Jan 24, 2002 at 10:27:12AM -0500, Bill Stoddard wrote: > In the cases where we want/need a shared scoreboard, I would prefer for the parent to > derive a safe name and tell the child the name. I see no goodness in complicating the > config with a directive that does not provide a distinct benefit to the user. IMHO, >the > name of the shared segment (and the process for deriving the name) is best kept >under the > covers. Deriving a filename for the scoreboard may be more difficult than it sounds -- we don't want the file to reside on an NFS partition. -aaron
Re: app (Apache) references errno, threads in app use __errno2()
On Thu, Jan 24, 2002 at 08:09:04AM -0800, Justin Erenkrantz wrote: [snip] > Two major gotchas here: > > - Apache 1.3 is built with Forte. Module is built with gcc. > This almost never works. I'm shocked it even ran. mod_webapp > runs into all sorts of problems when this mismatch occurrs. > The compilers have different ideas about lots of things, so > there could be a mismatch in how errno is handled. With C this isn't a problem as long as you use the same linker (think of system libraries). The problems we've seen on this mismatch were really a bug in the interaction between gcc and solaris' ld. In short, gcc would compile against symbols in libgcc, but would not provide the linker with the implicit path to that library. Whenver you see problems with __floatdisf and the like, this is probably what's going on. Please enlighten me if I'm incorrect here. > - Building httpd without _THREAD_SAFE with a module compiled for > _THREAD_SAFE is the root of your problem. This goes to the > discussion Aaron and I had a few days ago about always compiling > with _REENTRANT/thread-safety flags in httpd-2.0. I know that > Solaris goes wonky when this mismatch occurs - it's entirely > unpredictable - which seems to be what's happening here. > > Sorry, but I think Apache 1.3 just needs to be recompiled with > _THREAD_SAFE and with the same compiler as the module. Anything > else is just asking for trouble like this. Yes, this is how I understand it. > However, if this error occurs with a _THREAD_SAFE/same-compiler > build, then it's something we should look into. I just wouldn't > put any money on that happening. -- justin Totally agree. -aaron
Re: Members of dev@httpd.apache.org
On Thu, Jan 24, 2002 at 01:17:17PM +0100, Günter Knauf wrote: [snip] > according to your suggestions I ask now: why I get no feedback? > Not even a 'NO - not accepted'; simply nothing... Please supply a patch that we can review. I see no reason why we can't make such a change. -aaron
mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Greg Ames wrote: > I don't remember seeing a fix for the recursive subrequest loops involving > mod_negotiation. some more info on this problem. gdb refuses to produce a decent backtrace from the coredumps, maybe because of the unusual depth of the call stack. So I had a hard time getting any meaningful info that way. But we do have the backtrace from when I attached gdb to a live looping process - the message ID is in the STATUS file (thanks, Justin). So I vi'd the 4 dumps, looking for the input buffers. They all reference host: jakarta.apache.org, and the request lines look very similar: GET /builds/tomcat/release/v3.1/bin/ <== two of these GET /builds/tomcat/release/v3.2/bin/ GET /builds/jakarta-tomcat/release/v3.2/bin/ /builds/tomcat/ is redirected to /builds/jakarta-tomcat/ via an .htaccess file, so the bottom two refer to the same thing. All of these refer to paths that no longer exist: [gregames@daedalus gregames]$ ls /www/jakarta.apache.org/builds/jakarta-tomcat/release CVS v3.2.3 v3.2.4-beta-1 v3.3.old v3.1.1 v3.2.4 v3.3 The backtrace I posted showed that apr_filepath_merge's addpath arg was "builds/tomcat/release/v3.1/v3.1.1/v3.1.1/v3.1.1/..." This comes from r->filename in ap_directory_walk. That seems odd in a few ways, beside the ever growing bogus path. * why would we try to negotiate at all, when the only candidates are directories, not files? * it looks like we might be triggering some 1.3 negotiation behavior, where any extention under the sun is a match. We use MultiviewsMatch Handlers, so .asis and .cgi extentions do not need to be specified in the URI. * why do we see /builds/tomcat/ rather than /builds/jakarta-tomcat/ in r->filename? I would think the redirect would happen early, and subsequent filenames would contain the new path. Probably not important, because we got the same loop when jakarta-tomcat was part of the original URI. Greg
Re: cvs commit: apache-devsite how-to-release.html
Justin Erenkrantz wrote: > > On Thu, Jan 24, 2002 at 04:16:50PM -, [EMAIL PROTECTED] wrote: > > jim 02/01/24 08:16:50 > > > > Modified:.how-to-release.html > > Log: > > Some changes due to reorg > > All of these docs are in httpd-site/xdocs/dev. > > I believe that version is up-to-date, but please check. > > apache-devsite and dev.apache.org are no longer used. -- justin > I just wanted to sync up dev.apache.org, which still exists, just in case. I'm still updating some of the other files... -- === 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"
RE: cvs commit: httpd-2.0/server scoreboard.c
> On Thu, Jan 24, 2002 at 11:23:39AM -0500, Bill Stoddard wrote: > > The issue is not whether we need a "file" backing the scoreboard. On > Unix, you make the > > scoreboard use a file when the OS does not support shared memory. > > I think Aaron pointed out in a recent exchange with a FreeBSD user > that we don't support any OS without shared memory (FreeBSD disables > shmem in a jail). IIRC, file-backed scoreboards are no longer > supported in 2.0 (i.e. no use of shmem at all). Some OSes require > a path to "setup" the scoreboard via shmem. FWIW, this seems > identical to your issue in Win32. > > (I could be wrong, but that is my interpretation.) -- justin I think you are 100% spot on, which was my original point. Unix requires a filename to be setup for most shared memory implementations. Windows should work exactly the same way, right down to supporting the ScoreBoardFile directive. Ryan
Re: cvs commit: httpd-2.0/server scoreboard.c
On Thu, Jan 24, 2002 at 11:23:39AM -0500, Bill Stoddard wrote: > The issue is not whether we need a "file" backing the scoreboard. On Unix, you make >the > scoreboard use a file when the OS does not support shared memory. I think Aaron pointed out in a recent exchange with a FreeBSD user that we don't support any OS without shared memory (FreeBSD disables shmem in a jail). IIRC, file-backed scoreboards are no longer supported in 2.0 (i.e. no use of shmem at all). Some OSes require a path to "setup" the scoreboard via shmem. FWIW, this seems identical to your issue in Win32. (I could be wrong, but that is my interpretation.) -- justin
Re: cvs commit: httpd-2.0/server scoreboard.c
> > > > Bill, > > > > This triggered a question... > > > > > > > > I have not followed the discussion on this thread closely, but are > you > > requiring the > > > > ScoreBoardFile directive on Windows to name the shmem? I hope > > not. > > > > > > At this moment, yes, otherwise it defaults to the parent/private, > > child/private > > > model. Do you want that changed, effective now, to always have a > shared > > score? > > > It must become a shared score before we can proceed to > multi-process, > > but we > > > aren't quite there, yet. > > > > > > Bill > > > > > > > In the cases where we want/need a shared scoreboard, I would prefer > for > > the parent to > > derive a safe name and tell the child the name. I see no goodness in > > complicating the > > config with a directive that does not provide a distinct benefit to > the > > user. IMHO, the > > name of the shared segment (and the process for deriving the name) is > best > > kept under the > > covers. > > Just to be clear, that is not what Unix does now. If you need a file > backing the scoreboard, we make you add one. > > Ryan The issue is not whether we need a "file" backing the scoreboard. On Unix, you make the scoreboard use a file when the OS does not support shared memory. On Unix systems that support shared memory, we create the shared memory in the parent, fork and the child processes automagically have access to that shared memory. Windows does not support fork, so the shared memory created in the parent needs to become visible to the child processes some how. One way to make that shared memory visible is to give it a name that the parent and child processes know. My question/concern was how to communicate that name. I do NOT want to REQUIRE an admin to explicitly name the shared memory segment with a config directive. If he wants to, fine but it should not be a requirement, just as it is not a requirement on Unix today. If my explanation was not sufficient, talk to Bill Rowe, cause I think we see eye-to-eye on this based on our last exchange. That will save me typing and list subscribers reading :-) Bill > >
Re: cvs commit: apache-devsite how-to-release.html
On Thu, Jan 24, 2002 at 04:16:50PM -, [EMAIL PROTECTED] wrote: > jim 02/01/24 08:16:50 > > Modified:.how-to-release.html > Log: > Some changes due to reorg All of these docs are in httpd-site/xdocs/dev. I believe that version is up-to-date, but please check. apache-devsite and dev.apache.org are no longer used. -- justin
RE: cvs commit: httpd-2.0/server scoreboard.c
> > > Bill, > > > This triggered a question... > > > > > > I have not followed the discussion on this thread closely, but are you > requiring the > > > ScoreBoardFile directive on Windows to name the shmem? I hope > not. > > > > At this moment, yes, otherwise it defaults to the parent/private, > child/private > > model. Do you want that changed, effective now, to always have a shared > score? > > It must become a shared score before we can proceed to multi-process, > but we > > aren't quite there, yet. > > > > Bill > > > > In the cases where we want/need a shared scoreboard, I would prefer for > the parent to > derive a safe name and tell the child the name. I see no goodness in > complicating the > config with a directive that does not provide a distinct benefit to the > user. IMHO, the > name of the shared segment (and the process for deriving the name) is best > kept under the > covers. Just to be clear, that is not what Unix does now. If you need a file backing the scoreboard, we make you add one. Ryan
Re: cvs commit: httpd-2.0/server scoreboard.c
> > > > Bill, > > > > This triggered a question... > > > > > > > > I have not followed the discussion on this thread closely, but are you >requiring the > > > > ScoreBoardFile directive on Windows to name the shmem? I hope not. > > > > > > At this moment, yes, otherwise it defaults to the parent/private, child/private > > > model. Do you want that changed, effective now, to always have a shared score? > > > It must become a shared score before we can proceed to multi-process, but we > > > aren't quite there, yet. > > > > In the cases where we want/need a shared scoreboard, I would prefer for the parent >to > > derive a safe name and tell the child the name. I see no goodness in complicating >the > > config with a directive that does not provide a distinct benefit to the user. IMHO, the > > name of the shared segment (and the process for deriving the name) is best kept >under the > > covers. > > You didn't answer my question :) You answered my question with a question :-) Seriously... I'm a bit of a performance nut. If the shared scoreboard does not impose a performance hit, then may as well begin using it (assuming it even works of course:-). We clearly need to introduce multiple child processes under Windows and the shared score is a prereq. > First off, to your response, IF the user > specifies a filename, I strongly believe we use that name. +1 > If the user > leaves ScoreboardFile unspecified, then we do what _we_ feel is best. > I believe this applies to Win32 and Unix, as well, and made that comment > to Aaron's patch. +1 > > Now, if the user doesn't specify a ScoreboardFile _today_, then we leave > well enough alone, and the parent and child don't share a scoreboard. > That's fine, until we go to multiple processes. Unless we want to begin > using the shared score today, always. > > As far as our inventing that shared resource [If the user assign the file > backing with ScoreboardFile]; I have a philosophy. You create the child > detached. We dup the handle to the shared score to the child's process, > and pass it down the pipe. > > We need the apr_os_shm_get/put to make this happen, but that's a trivial > patch. My Q to you - share a scoreboard, starting today, always? Or only > if we actually care? [3rd party module/app or when we get to multi-proc.] I was not able to parse all of the last two paragraphs... Any downsides to a shared score today? If not, then lets begin using a shared score now. Bill > Bill >
Re: app (Apache) references errno, threads in app use __errno2()
On Thu, Jan 24, 2002 at 10:50:43AM -0500, Jeff Trawick wrote: > The following message is a courtesy copy of an article > that has been posted to comp.unix.solaris as well. > > I could use some Solaris-specific insight here. > > I suspect that the best situation is that all code is compiled with > _THREAD_SAFE so that everybody uses __errno2(), but I have a situation > where that isn't the case and I'm trying to figure out if it is a > problem. Here's the situation: > > + Apache 1.3 built with Sun compiler without _THREAD_SAFE > > + module for Apache built with gcc with _THREAD_SAFE; the module > creates other threads that run in the Apache processes I've written an Apache 1.3 module that used threads on Solaris (the thread usage was implicit behind door calls), so I know it's fine as long as you play nicely. Two major gotchas here: - Apache 1.3 is built with Forte. Module is built with gcc. This almost never works. I'm shocked it even ran. mod_webapp runs into all sorts of problems when this mismatch occurrs. The compilers have different ideas about lots of things, so there could be a mismatch in how errno is handled. - Building httpd without _THREAD_SAFE with a module compiled for _THREAD_SAFE is the root of your problem. This goes to the discussion Aaron and I had a few days ago about always compiling with _REENTRANT/thread-safety flags in httpd-2.0. I know that Solaris goes wonky when this mismatch occurs - it's entirely unpredictable - which seems to be what's happening here. Sorry, but I think Apache 1.3 just needs to be recompiled with _THREAD_SAFE and with the same compiler as the module. Anything else is just asking for trouble like this. However, if this error occurs with a _THREAD_SAFE/same-compiler build, then it's something we should look into. I just wouldn't put any money on that happening. -- justin
apache-site... never mind
Ack. It's the httpd-dist tree -- === 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"
app (Apache) references errno, threads in app use __errno2()
The following message is a courtesy copy of an article
that has been posted to comp.unix.solaris as well.
I could use some Solaris-specific insight here.
I suspect that the best situation is that all code is compiled with
_THREAD_SAFE so that everybody uses __errno2(), but I have a situation
where that isn't the case and I'm trying to figure out if it is a
problem. Here's the situation:
+ Apache 1.3 built with Sun compiler without _THREAD_SAFE
+ module for Apache built with gcc with _THREAD_SAFE; the module
creates other threads that run in the Apache processes
Can something done by that module's "extra" threads confuse Apache
when it looks at errno? Shouldn't Apache and that module's threads be
referencing different storage for errno?
The problem is that something bad is happening in this code:
static void accept_mutex_on_sysvsem(void)
{
while (semop(sem_id, &op_on, 1) < 0) {
if (errno != EINTR) {
perror("accept_mutex_on");
clean_child_exit(APEXIT_CHILDFATAL);
}
}
}
Under circumstances I can't (yet) recreate, this code exits with this
message written to stderr:
accept_mutex_on: Interrupted system call
I interpret this as meaning that one of the following things occurred:
1) there is a compiler bug causing us to exit when errno was EINTR
instead of when errno wasn't EINTR
2) there is a bug in Solaris perror() which causes you to get the
EINTR message for errnos other than EINTR
3) some other thread is overlaying the errno checked for by the code
above and/or by perror()
Any ideas?
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/server scoreboard.c
> > > Bill, > > > This triggered a question... > > > > > > I have not followed the discussion on this thread closely, but are you requiring >the > > > ScoreBoardFile directive on Windows to name the shmem? I hope not. > > > > At this moment, yes, otherwise it defaults to the parent/private, child/private > > model. Do you want that changed, effective now, to always have a shared score? > > It must become a shared score before we can proceed to multi-process, but we > > aren't quite there, yet. > > In the cases where we want/need a shared scoreboard, I would prefer for the parent to > derive a safe name and tell the child the name. I see no goodness in complicating the > config with a directive that does not provide a distinct benefit to the user. IMHO, >the > name of the shared segment (and the process for deriving the name) is best kept >under the > covers. You didn't answer my question :) First off, to your response, IF the user specifies a filename, I strongly believe we use that name. If the user leaves ScoreboardFile unspecified, then we do what _we_ feel is best. I believe this applies to Win32 and Unix, as well, and made that comment to Aaron's patch. Now, if the user doesn't specify a ScoreboardFile _today_, then we leave well enough alone, and the parent and child don't share a scoreboard. That's fine, until we go to multiple processes. Unless we want to begin using the shared score today, always. As far as our inventing that shared resource [If the user assign the file backing with ScoreboardFile]; I have a philosophy. You create the child detached. We dup the handle to the shared score to the child's process, and pass it down the pipe. We need the apr_os_shm_get/put to make this happen, but that's a trivial patch. My Q to you - share a scoreboard, starting today, always? Or only if we actually care? [3rd party module/app or when we get to multi-proc.] Bill
Re: cvs commit: httpd-2.0/server scoreboard.c
> From: "Bill Stoddard" <[EMAIL PROTECTED]> > Sent: Thursday, January 24, 2002 8:57 AM > > > > Bill, > > This triggered a question... > > > > I have not followed the discussion on this thread closely, but are you requiring >the > > ScoreBoardFile directive on Windows to name the shmem? I hope not. > > At this moment, yes, otherwise it defaults to the parent/private, child/private > model. Do you want that changed, effective now, to always have a shared score? > It must become a shared score before we can proceed to multi-process, but we > aren't quite there, yet. > > Bill > In the cases where we want/need a shared scoreboard, I would prefer for the parent to derive a safe name and tell the child the name. I see no goodness in complicating the config with a directive that does not provide a distinct benefit to the user. IMHO, the name of the shared segment (and the process for deriving the name) is best kept under the covers. Bill
Re: cvs commit: httpd-2.0/server scoreboard.c
From: "Bill Stoddard" <[EMAIL PROTECTED]> Sent: Thursday, January 24, 2002 8:57 AM > Bill, > This triggered a question... > > I have not followed the discussion on this thread closely, but are you requiring the > ScoreBoardFile directive on Windows to name the shmem? I hope not. At this moment, yes, otherwise it defaults to the parent/private, child/private model. Do you want that changed, effective now, to always have a shared score? It must become a shared score before we can proceed to multi-process, but we aren't quite there, yet. Bill
Re: cvs commit: httpd-2.0/modules/dav/fs lock.c repos.c
From: "Greg Stein" <[EMAIL PROTECTED]>
Sent: Thursday, January 24, 2002 4:09 AM
> On Wed, Jan 23, 2002 at 06:28:06PM -, [EMAIL PROTECTED] wrote:
> >...
> > @@ -837,7 +844,8 @@
> >return NULL;
> >}
> >
> > -if (apr_file_info_get(&finfo, APR_FINFO_NORM, file) != APR_SUCCESS) {
> > +rv = apr_file_info_get(&finfo, APR_FINFO_NORM, file);
>
> Looking at the usage of 'finfo', this could be APR_FINFO_SIZE
Yup, I had limited time ... so I simply made it work. That patch can definately
be optimized based on the context of the apr_file_info_get and lstat changes!
> >...
> > @@ -1042,7 +1050,6 @@
> >return err;
> >}
> >
> > -#ifndef WIN32
> >{
> >dav_lock_discovery *ld;
> >dav_lock_indirect *id;
> > @@ -1071,7 +1078,6 @@
> >return err;
> >}
> >}
> > -#endif
>
> Hmm. Debatable change. It could end up removing a lock record, then putting
> it right back. I don't think it is a real problem, tho.
Goal 1 of APR, module code doesn't use #if PLAT fooness, or it will discover
itself borked in future ports :) Is there a trivial patch to discover [or cache]
the fact that the platform won't support the feature?
> >...
> > --- repos.c 14 Jan 2002 13:43:24 - 1.56
> > +++ repos.c 23 Jan 2002 18:28:05 - 1.57
> >...
> > @@ -705,16 +733,12 @@
> >dav_resource_private *ctx = resource->info;
> >dav_resource_private *parent_ctx;
> >dav_resource *parent_resource;
> > +apr_status_t rv;
> >char *dirpath;
> >
> >/* If given resource is root, then there is no parent */
> >if (strcmp(resource->uri, "/") == 0 ||
> > -#ifdef WIN32
> > -(strlen(ctx->pathname) == 3 && ctx->pathname[1] == ':' &&
>ctx->pathname[2] == '/')
> > -#else
> > -strcmp(ctx->pathname, "/") == 0
> > -#endif
> > - ) {
> > +ap_os_is_path_absolute(ctx->pool, ctx->pathname)) {
>
> Bad and wrong.
>
> The former tested for "is this the root". ap_os_is_path_absolute() is not
> the same test. The end result is that none of the resources will have
> parents, which is going to *completely* break the lock tests.
Reviewing ... yup. This needs an apr_filepath_root() call, and test if we
have any remaining path info [if so, it isn't the root.] apr_filepath_root
slurps off the leading '/' in unix, the leading dir in win32/os2, and
//mach/share on win32 (os2?) and mach:/share on netware.
Correct? I'll fix.
> >...
> > @@ -1171,13 +1195,21 @@
> >else {
> >const char *dirpath;
> >apr_finfo_t finfo;
> > +apr_status_t rv;
> >
> >/* destination does not exist, but the parent directory should,
> >* so try it
> >*/
> >dirpath = ap_make_dirstr_parent(dstinfo->pool, dstinfo->pathname);
> > - if (apr_stat(&finfo, dirpath, APR_FINFO_NORM, dstinfo->pool) == 0
> > - && finfo.device == srcinfo->finfo.device) {
> > +/*
> > + * XXX: If missing dev ... then what test?
> > + * Really need a try and failover for those platforms.
> > + *
> > + */
> > +rv = apr_stat(&finfo, dirpath, APR_FINFO_DEV, dstinfo->pool);
> > + if ((rv == APR_SUCCESS || rv == APR_INCOMPLETE)
> > +&& (finfo.valid & srcinfo->finfo.valid & APR_FINFO_DEV)
> > + && (finfo.device == srcinfo->finfo.device)) {
> >can_rename = 1;
>
> If the device doesn't exist or doesn't match, then it just does a copy.
My question was; can this be a tristate (can_rename, try_rename, must_copy)
for platforms that can't tell us in advance about .dev? It's preferable
to fail-over in the try_rename case, I would expect.
> >...
> > @@ -1868,11 +1900,11 @@
> >{
> >const dav_liveprop_spec *info;
> >
> > -#ifndef WIN32
> > -/* this property is not usable (writable) on the Win32 platform */
> > +/* XXX this property is not usable (writable) on all platforms
> > + * Need an abstract way to determine this.
> > + */
> >if (propid == DAV_PROPID_FS_executable && !resource->collection)
> >return 1;
> > -#endif
>
> This is a bad change. Unless/until you get the query, then you should not be
> removing this check. You're now advertising a property as being present, but
> is ineffectual.
>
> There are clients out there today which know and handle this custom
> property. You're breaking them.
I'll revert, for now.
> >...
> > @@ -2036,10 +2068,11 @@
> >
> >void dav_fs_gather_propsets(apr_array_header_t *uris)
> >{
> > -#ifndef WIN32
> > +/* XXX: Need an abstract way to determine this on a per-filesystem basis
> > + * This may change by uri (!) (think OSX HFS + unix mounts).
> > + */
> >*(const char **)apr_array_push(uris) =
> >"";
> > -#endif
> >}
same here.
> >...
> > @@ -2077,16 +2110,8 @@
> > what, phdr);
> >(void) dav
Re: cvs commit: httpd-2.0/server scoreboard.c
Bill, This triggered a question... I have not followed the discussion on this thread closely, but are you requiring the ScoreBoardFile directive on Windows to name the shmem? I hope not. Bill > > aaron 02/01/22 22:51:18 > > > > Modified:server scoreboard.c > > Log: > > Although this patch is technically correct, I'm not happy with > > the way it gets things done. OTOH, it is a simple enough change > > to get things working correctly for now. I will come up with > > the right way to do this in the next couple days. > > > > This patch re-enables the use of anonymous shared memory in the > > scoreboard on platforms that have it. > > Well chicken 'n eggs... one way or another this patch broke win32. > > Now I'm researching what/how to get both anon and file backed win32 > shm.c working. Fixing that bug makes the win32 startup failures > disappear. > > But this does break a simple idea behind the win32 shmem. I had > intended to create the scoreboard as shared, only if named. The > create anon _does_ create anon memory on win32, ENOTIMPL is not > an acceptable solution. > > The issue is that we are a forked platform. Therefore, you can't > make the assumption that anon is preferred. Maybe you prefer it, > but we on win32 sure don't, and other platforms may agree for other > reasons. > > So I suggest we back out the patch, and instead, use this logic; > rather than always creating the DEFAULT scoreboard name, leave it > Null on all platforms that support anon memory. If the user specifies > a filename, use it. If the user omits the ScoreboardName, then they > receive anon memory. And if APR lacks anon support, keep using a > default scoreboard name on the platform. > > Does this make any sense? It would allow 3rd party apps to share and > access the scoreboard by name, when the user configures it, and regardless > of our default preference for that platform. > > Bill >
Is apache-site no longer appropriate?
With the new layout, it looks like the old way of changing the site info is no longer correct... apache-site for me is unavailable and I can't find out where to make the required changes to make the site reflect the changes in dist/httpd. This is to adjust the Announcement et.al files... Thanks -- === 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"
DocumentRoot Re: Members of dev@httpd.apache.org
Sander Striker wrote: >>From: Gunter Knauf [mailto:[EMAIL PROTECTED]] >> ... >>Hi, >>some others and I would like to have the DocumentRoot marked: >> >>- DocumentRoot "@@ServerRoot@@/htdocs" >>+ DocumentRoot "@@DocumentRoot@@" >> >>and: >> >>- >>+ >> >>so that we can replace the complete path to the document root by script. >> >>can we change this? >> >>--- ENDE DER WEITERGELEITETEN NACHRICHT-- >> >>according to your suggestions I ask now: why I get no feedback? >>Not even a 'NO - not accepted'; simply nothing... >> > >This is mainly because everyone is also extremely busy. And, >on top of that, everyone works in their own area of interest. >When a patch doesn't get feedback within a reasonable amount of >time, simply repost it, stating that it is a repost meant as >a simple reminder that it is there. > >To give you some feedback: personally I think there might be >a point in your suggestion to moving to @@DocumentRoot@@. > +1 on @@DocumentRoot@@ --Brian
[PATCH] log cookie values in 1.3
I copied the %C{CookieName} log variable from Apache 2 to 1.3
--
Brian Akins
Systems Engineer III
CNN Internet Technologies
--- src/modules/standard/mod_log_config.c Mon Jan 15 12:05:44 2001
+++ /home/bakins/src/apache_1.3.22/src/modules/standard/mod_log_config.c Thu Jan 17 08:01:43 2002
/*
* multi_log_state is our per-(virtual)-server configuration. We store
@@ -482,6 +495,28 @@ static const char *log_connection_status
return "-";
}
+
+static const char *log_cookie(request_rec *r, char *a)
+{
+const char *cookies;
+const char *start_cookie;
+
+if ((cookies = ap_table_get(r->headers_in, "Cookie"))) {
+if ((start_cookie = strstr(cookies,a))) {
+char *cookie, *end_cookie;
+start_cookie += strlen(a) + 1; /* cookie_name + '=' */
+cookie = ap_pstrdup(r->pool, start_cookie);
+/* kill everything in cookie after ';' */
+end_cookie = strchr(cookie, ';');
+if (end_cookie) {
+*end_cookie = '\0';
+}
+
+return cookie;
+}
+}
+return "-";
+}
/*
*
* Parsing the log format string
@@ -567,6 +602,9 @@ static struct log_item_list {
},
{
'c', log_connection_status, 0
+},
+{
+'C', log_cookie, 0
},
{
'\0'
Patch to handle User in VirtualHost against 1.3.20
Hello,
we've needed functionality of Apache 2 MPM's specially one which
allows VirtualHost to run under different UID.
Because Apache 2 is still in beta I patched our production 1.3.20
by attached patch. It simply does seteuid instead of setuid and
later in ap_read_request it regains root and uses setuid to UID
set by User directive. Furthermore I have to ensure that child
processes only one connection and exits.
I tested it with PHP and seems to work smoothly.
Maybe it could help someone looking for better PHP security
than safemode and who can't use CGI version of PHP.
It would be nice if someone experienced with apache internals
could comment the patch.
I'm aware of performance problem: only one connection handled
by single child. I measured 7% slowdown on our server. It is
worth of better security for us.
I'm not sure whether real-uid == 0 between child start and
ap_read_request can impose security/stability problem. I found
nothing such.
best regards, devik
diff -pru src/main/old/http_core.c src/main/http_core.c
--- src/main/old/http_core.cThu Jan 24 13:54:25 2002
+++ src/main/http_core.cThu Jan 24 14:11:46 2002
@@ -2038,15 +2038,7 @@ static const char *set_user(cmd_parms *c
cmd->server->server_uid = ap_user_id = ap_uname2id(arg);
}
else {
-if (ap_suexec_enabled) {
cmd->server->server_uid = ap_uname2id(arg);
- }
- else {
- cmd->server->server_uid = ap_user_id;
- fprintf(stderr,
- "Warning: User directive in "
- "requires SUEXEC wrapper.\n");
- }
}
#if !defined (BIG_SECURITY_HOLE) && !defined (OS2)
if (cmd->server->server_uid == 0) {
diff -pru src/main/old/http_main.c src/main/http_main.c
--- src/main/old/http_main.cThu Jan 24 13:54:25 2002
+++ src/main/http_main.cThu Jan 24 14:58:03 2002
@@ -3963,9 +3963,9 @@ static void child_main(int child_num_arg
#ifdef _OSD_POSIX
os_init_job_environment(server_conf, ap_user_name, one_process) != 0 ||
#endif
- setuid(ap_user_id) == -1)) {
+ seteuid(ap_user_id) == -1)) {
ap_log_error(APLOG_MARK, APLOG_ALERT, server_conf,
- "setuid: unable to change to uid: %ld", (long) ap_user_id);
+ "seteuid: unable to change to uid: %ld", (long) ap_user_id);
clean_child_exit(APEXIT_CHILDFATAL);
}
#endif
@@ -4361,6 +4361,7 @@ static void child_main(int child_num_arg
ap_bclose(conn_io);
}
#endif
+ clean_child_exit(0); /* only one request in our hacked mode */
}
}
@@ -5178,10 +5179,10 @@ int REALMAIN(int argc, char *argv[])
}
GETUSERMODE();
#else
- /* Only try to switch if we're running as root */
- if (!geteuid() && setuid(ap_user_id) == -1) {
+ /* Only try to switch if we're running as root; HACK: we use seteuid now */
+ if (!geteuid() && seteuid(ap_user_id) == -1) {
ap_log_error(APLOG_MARK, APLOG_ALERT, server_conf,
- "setuid: unable to change to uid: %ld",
+ "seteuid: unable to change to uid: %ld",
(long) ap_user_id);
exit(1);
}
diff -pru src/main/old/http_protocol.c src/main/http_protocol.c
--- src/main/old/http_protocol.cThu Jan 24 13:54:25 2002
+++ src/main/http_protocol.cThu Jan 24 14:35:51 2002
@@ -1173,6 +1173,13 @@ request_rec *ap_read_request(conn_rec *c
*/
ap_update_vhost_from_headers(r);
+ /* HACK: regain root & become indicated user */
+ if (seteuid (0)) ap_log_rerror(APLOG_MARK, APLOG_ERR, r, "can't regain root");
+
+ if (setuid (r->server->server_uid) || setgid (r->server->server_gid))
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, r,
+ "can't setuid to user defined UID (%d)", r->server->server_uid);
+
/* we may have switched to another server */
r->per_dir_config = r->server->lookup_defaults;
Re: Apache 1.3.23 tarballs...
have been moved to the www.apache.org/dist/httpd area now, to give the mirrors time to grab them. Will Announce either later tonite or tomorrow. -- === 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"
Re: Current CVS on Win32
Ian Holsman wrote: > yep it's broken. > standard httpd.conf file doesn't start. > looks like it dies just after opening the errorlog file > > It works with -D ONE_PROCESS btw.. > interesting... HEAD works again for me. Thanks, Sebastian -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
RE: Current CVS on Win32
> From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]] > Sent: 24 January 2002 14:21 > To: [EMAIL PROTECTED] > Subject: Current CVS on Win32 > > > ... does not build: > > apr_pools.c > c:\home\apache\httpd-2.0\srclib\apr\memory\unix\apr_pools.c(73): > fatal error C1083: include file not found: 'unistd.h': > No such file or directory Ahum, my bad, so it seems. Where is getpid() located in win32? > There seems to be something amiss here, since it tries to build a *NIX > specific part of the library, I suppose. And, hang on for the next commit to the pools code in about 5 minutes. Sorry for the inconvenience. Sander
Current CVS on Win32
... does not build: apr_pools.c c:\home\apache\httpd-2.0\srclib\apr\memory\unix\apr_pools.c(73): fatal error C1083: include file not found: 'unistd.h': No such file or directory There seems to be something amiss here, since it tries to build a *NIX specific part of the library, I suppose. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
Re: [HEAD] --with-mpm=worker under FreeBSD 4.5 does nothing?
On Wed, 23 Jan 2002, Aaron Bannert wrote: > > Now, does apache2 *require* shared memory, or can I set all of the above > > to zero, and it will work around the limitation? > > If you wish to run apache with multiple processes, then shared memory > is necessary. How did Apache1 deal with this? It ran multiple processes, but had no shared memory requirement ...
RE: mod_cgid pipe leak
> > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick > > Sent: 24 January 2002 13:44 > > To: [EMAIL PROTECTED] > > Cc: Aaron Bannert; Bill Stoddard; [EMAIL PROTECTED] > > Subject: Re: mod_cgid pipe leak > > > > > > Jeff Trawick <[EMAIL PROTECTED]> writes: > > > > > I'll try to follow up with an strace of the cgid daemon across a > > > CGI... gotta rebuild (I always seem to have the wrong config for > > > what I want to do next... maybe some cron jobs need to keep a couple > > > of build flavors current :) ) > > > > This is current HEAD on Linux (with some apr_pools.c code ifdef-ed > > out so it woud compile... whats up with that?). > > Damn, damn, damn. Please tell me what you #ifdef-ed out, so I can fix > it. Ok, I think I see the problem. Sorry about that. Sander
RE: mod_cgid pipe leak
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick > Sent: 24 January 2002 13:44 > To: [EMAIL PROTECTED] > Cc: Aaron Bannert; Bill Stoddard; [EMAIL PROTECTED] > Subject: Re: mod_cgid pipe leak > > > Jeff Trawick <[EMAIL PROTECTED]> writes: > > > I'll try to follow up with an strace of the cgid daemon across a > > CGI... gotta rebuild (I always seem to have the wrong config for > > what I want to do next... maybe some cron jobs need to keep a couple > > of build flavors current :) ) > > This is current HEAD on Linux (with some apr_pools.c code ifdef-ed > out so it woud compile... whats up with that?). Damn, damn, damn. Please tell me what you #ifdef-ed out, so I can fix it. Sander
Re: mod_cgid pipe leak
Jeff Trawick <[EMAIL PROTECTED]> writes:
> I'll try to follow up with an strace of the cgid daemon across a
> CGI... gotta rebuild (I always seem to have the wrong config for
> what I want to do next... maybe some cron jobs need to keep a couple
> of build flavors current :) )
This is current HEAD on Linux (with some apr_pools.c code ifdef-ed
out so it woud compile... whats up with that?).
accept(6, {sin_family=AF_UNIX, path=@
020fwick/apacheinst/logs/cgisock}, [11]) = 7
read(7, "\1\0\0\0", 4) = 4
read(7, "\22\0\0\0", 4) = 4
read(7, "\23\3\0\0", 4) = 4
read(7, "/home/trawick/apacheinst/cgi-bin"..., 787) = 787
read(7, "\0\0\0\0", 4) = 4
pipe([10, 12]) = 0
fcntl(12, F_GETFL) = 0x1 (flags O_WRONLY)
fcntl(12, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
pipe([15, 17]) = 0
fcntl(15, F_GETFL) = 0 (flags O_RDONLY)
fcntl(15, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
pipe([18, 19]) = 0
fcntl(18, F_GETFL) = 0 (flags O_RDONLY)
fcntl(18, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
dup(2) = 20
dup(7) = 21
dup(7) = 22
close(7)= 0
fork() = 14788
close(21) = 0
close(22) = 0
close(20) = 0
close(-1) = -1 EBADF (Bad file
descriptor)
close(18) = 0
close(-1) = -1 EBADF (Bad file
descriptor)
close(15) = 0
close(12) = 0
close(-1) = -1 EBADF (Bad file
descriptor)
accept(6, 0xb968, [110])= ? ERESTARTSYS (To be
restarted)
--- SIGCHLD (Child exited) ---
accept(6,
After running a 3 CGI requests through, lsof shows this:
lt-httpd 14710 trawick0r CHR1,3 4101 /dev/null
lt-httpd 14710 trawick1w CHR1,3 4101 /dev/null
lt-httpd 14710 trawick2u REG3,5 62818 2050
/home/trawick/apacheinst/logs/error_log
lt-httpd 14710 trawick3u IPv4 824589TCP *:
(LISTEN)
lt-httpd 14710 trawick4u IPv4 824590TCP *:tproxy
(LISTEN)
lt-httpd 14710 trawick5u REG3,5 62818 2050
/home/trawick/apacheinst/logs/error_log
lt-httpd 14710 trawick6u unix 0xc06ef240 824604
/home/trawick/apacheinst/logs/cgisock
lt-httpd 14710 trawick8r FIFO0,0 824620 pipe
lt-httpd 14710 trawick9r FIFO0,0 824633 pipe
lt-httpd 14710 trawick 10r FIFO0,0 824641 pipe
lt-httpd 14710 trawick 11w FIFO0,0 824621 pipe
lt-httpd 14710 trawick 13w FIFO0,0 824622 pipe
lt-httpd 14710 trawick 14w FIFO0,0 824634 pipe
lt-httpd 14710 trawick 16w FIFO0,0 824635 pipe
lt-httpd 14710 trawick 17w FIFO0,0 824642 pipe
lt-httpd 14710 trawick 19w FIFO0,0 824643 pipe
So we lose 3 pipe descriptors per request.
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: Members of dev@httpd.apache.org
Hi Johan, > And, a bit more technical, where can I find a very good but free CVS > client for windows? below my batch which works from NT; with W9x you probably have to 'set HOME=.' or something like that... @echo off rem Win32 CVS available at: http://www.cvshome.org/dev/codewindow.html echo Batch for fetching Apache httpd-2.0 sources from CVS. echo First do a login. Password: (enter "anoncvs") echo. cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login if not errorlevel 0 goto end echo Now get httpd-2.0 tree echo. cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co httpd-2.0 cd srclib cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co apr cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co apr-util :end
RE: Members of dev@httpd.apache.org
> From: Gunter Knauf [mailto:[EMAIL PROTECTED]] Hi Gunter, >> if you don't get feedback, ask why and if nobody answers or somebody >> says the change isn't appropriate make sure you understand why (but >> sometimes there is no good reason... collectively we're not perfect >> communicators I'm afraid) *grin* > --- HIER BEGINNT DIE WEITERGELEITETE NACHRICHT -- > Von: [EMAIL PROTECTED] (Guenter Knauf) > Datum: 14.01.2002, 13:26:35 > Betreff: mark Documentroot in httpd.conf > > Hi, > some others and I would like to have the DocumentRoot marked: > > - DocumentRoot "@@ServerRoot@@/htdocs" > + DocumentRoot "@@DocumentRoot@@" > > and: > > - > + > > so that we can replace the complete path to the document root by script. > > can we change this? > > --- ENDE DER WEITERGELEITETEN NACHRICHT-- > > according to your suggestions I ask now: why I get no feedback? > Not even a 'NO - not accepted'; simply nothing... This is mainly because everyone is also extremely busy. And, on top of that, everyone works in their own area of interest. When a patch doesn't get feedback within a reasonable amount of time, simply repost it, stating that it is a repost meant as a simple reminder that it is there. To give you some feedback: personally I think there might be a point in your suggestion to moving to @@DocumentRoot@@. > Guenter. Sander
Apache2 mod_auth_ldap
Hi, can someone please explain how I can create apr_ldap.h on Win32 and what additional defines are needed in the project in order to build mod_auth_ldap? Thanks, Guenter.
Re: Members of dev@httpd.apache.org
Hi, > if you don't get feedback, ask why and if nobody answers or somebody > says the change isn't appropriate make sure you understand why (but > sometimes there is no good reason... collectively we're not perfect > communicators I'm afraid) --- HIER BEGINNT DIE WEITERGELEITETE NACHRICHT -- Von: [EMAIL PROTECTED] (Guenter Knauf) Datum: 14.01.2002, 13:26:35 Betreff: mark Documentroot in httpd.conf Hi, some others and I would like to have the DocumentRoot marked: - DocumentRoot "@@ServerRoot@@/htdocs" + DocumentRoot "@@DocumentRoot@@" and: - + so that we can replace the complete path to the document root by script. can we change this? --- ENDE DER WEITERGELEITETEN NACHRICHT-- according to your suggestions I ask now: why I get no feedback? Not even a 'NO - not accepted'; simply nothing... Guenter.
Re: Members of dev@httpd.apache.org
"Udcsweb2" <[EMAIL PROTECTED]> writes: > What are the requirements for me to become a part of the development team? most of us started the same way... post a simple patch for a simple problem... use feedback from others to do it a little better/politically-correct the next time... in time anything can happen if you don't get feedback, ask why and if nobody answers or somebody says the change isn't appropriate make sure you understand why (but sometimes there is no good reason... collectively we're not perfect communicators I'm afraid) meanwhile, post a different patch for some other problem :) > In your eyes, what is the best route for me to follow to become acquainted with >the current HTTPD source? learn how to build Apache for your platform learn how to step through Apache code with a debugger look through the STATUS file for problems and take it as a challenge to see if you can reproduce the problem take it as a challenge to see if you can find the related source code for the problem take it as a challenge to see if you can change the code to get rid of the problem > And, a bit more technical, where can I find a very good but free CVS client for >windows? grab the wincvs package, forget about the GUI, and learn how to use the CVS command-line program (cvs.exe) > If any person receiving this takes offense towards any means of communication that I >introduce, please throw it at me. I have never even been part of a mailing list >before, and, as with any other internet communication service, I am sure that there >is an amount of ettiquete involved. I am more that willing to adhere. you could tell your e-mail software to wrap lines at 72 columns or so :) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Re: mod_cgid pipe leak
Aaron Bannert <[EMAIL PROTECTED]> writes: > [assuming you meant to post this to dev@httpd instead] > > On Thu, Jan 24, 2002 at 12:19:57AM -0500, Bill Stoddard wrote: > > >From STATUS > > > >* mod_cgid leaks pipe descriptors, apparently for every request. > > I would guess that this is due to recent apr_file_dup[2] > > changes. > > > > Is the leak in the cgid server process or the httpd process? > in the cgid server process > Could this be related to the other STATUS entry I just noticed? > > * Eliminate unnecessary creation of pipes in mod_cgid That is a long-standing problem. My "feeling" for the situation is that there is a long-standing API problem or mis-use of API by mod_cgid which leads to pipes being created unnecessarily there are long-standing bugs (duplicate cleanups?) that lead to invalid close calls (do strace on cgid daemon across a request to see several "close(-1)"; some of what you see now may be related to the pipe leak but some has been there for a long time there is something new introduced at about the time of recent apr_file_dup[2] work that introduced the leak I'll try to follow up with an strace of the cgid daemon across a CGI... gotta rebuild (I always seem to have the wrong config for what I want to do next... maybe some cron jobs need to keep a couple of build flavors current :) ) -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
another one... Re: cvs commit: httpd-2.0/modules/dav/fs lock.c repos.c
oops. missed this in my first response:
On Wed, Jan 23, 2002 at 06:28:06PM -, [EMAIL PROTECTED] wrote:
>...
> --- repos.c 14 Jan 2002 13:43:24 - 1.56
> +++ repos.c 23 Jan 2002 18:28:05 - 1.57
> @@ -244,17 +244,43 @@
>*fname_p = NULL;
>}
>else {
> +const char *testpath, *rootpath;
>char *dirpath = ap_make_dirstr_parent(ctx->pool, ctx->pathname);
>apr_size_t dirlen = strlen(dirpath);
> +apr_status_t rv = APR_SUCCESS;
>
> -if (fname_p != NULL)
> -*fname_p = ctx->pathname + dirlen;
> -*dirpath_p = dirpath;
Note that *dirpath_p was _always_ set.
> -
> -/* remove trailing slash from dirpath, unless it's the root dir */
> -/* ### Win32 check */
> -if (dirlen > 1 && dirpath[dirlen - 1] == '/') {
> -dirpath[dirlen - 1] = '\0';
> +testpath = dirpath;
> +if (dirlen > 0) {
> +rv = apr_filepath_root(&rootpath, &testpath, 0, ctx->pool);
> +}
> +
> +/* remove trailing slash from dirpath, unless it's a root path
> + */
> +if ((rv == APR_SUCCESS && testpath && *testpath)
> +|| rv == APR_ERELATIVE) {
> +if (dirpath[dirlen - 1] == '/') {
> +dirpath[dirlen - 1] = '\0';
> +}
> +}
> +
> +/* ###: Looks like a response could be appropriate
> + *
> + * APR_SUCCESS here tells us the dir is a root
> + * APR_ERELATIVE told us we had no root (ok)
> + * APR_EINCOMPLETE an incomplete testpath told us
> + * there was no -file- name here!
> + * APR_EBADPATHor other errors tell us this file
> + * path is undecipherable
> + */
> +
> +if (rv == APR_SUCCESS || rv == APR_ERELATIVE) {
> +*dirpath_p = dirpath;
> +if (fname_p != NULL)
> +*fname_p = ctx->pathname + dirlen;
> +}
> +else {
> +if (fname_p != NULL)
> +*fname_p = NULL;
>}
*dirpath_p is not set in the 'else' branch.
Also note that no callers expect those values to be set to NULL. Given that
the paths have been processed by Apache already, it's a good bet they are
always valid.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
release procedures (was: Re: Tagging .31 soon)
On Wed, Jan 23, 2002 at 09:50:40AM -0800, Ian Holsman wrote: >... > I think I'll just tag .31 and not roll it. If you have no intention of rolling a .31, then don't use that for the tag. A person can tag any time, but that must be with an intent to roll and release it. I think it is inappropriate to use Apache version numbers for what amounts to personal tags. Note that you also have a showstopper listed for a release. (in STATUS and/or at least with wrowe's veto). However, I believe the rule is more like, "the tarball can be released, but the *quality* is subject to consensus approval." In other words, it seems that you should be able to release the tarball, but would need to call it "alpha" or "development", but the group would shoot down things like "beta" or "final". [ this last part I'm a bit fuzzy on, so would like commentary from the *real* old-timers... ] Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: httpd-2.0/modules/dav/fs lock.c repos.c
On Wed, Jan 23, 2002 at 06:28:06PM -, [EMAIL PROTECTED] wrote:
>...
> @@ -837,7 +844,8 @@
> return NULL;
>}
>
> -if (apr_file_info_get(&finfo, APR_FINFO_NORM, file) != APR_SUCCESS) {
> +rv = apr_file_info_get(&finfo, APR_FINFO_NORM, file);
Looking at the usage of 'finfo', this could be APR_FINFO_SIZE
>...
> @@ -1042,7 +1050,6 @@
> return err;
>}
>
> -#ifndef WIN32
>{
> dav_lock_discovery *ld;
> dav_lock_indirect *id;
> @@ -1071,7 +1078,6 @@
> return err;
>}
>}
> -#endif
Hmm. Debatable change. It could end up removing a lock record, then putting
it right back. I don't think it is a real problem, tho.
>...
> --- repos.c 14 Jan 2002 13:43:24 - 1.56
> +++ repos.c 23 Jan 2002 18:28:05 - 1.57
>...
> @@ -705,16 +733,12 @@
>dav_resource_private *ctx = resource->info;
>dav_resource_private *parent_ctx;
>dav_resource *parent_resource;
> +apr_status_t rv;
>char *dirpath;
>
>/* If given resource is root, then there is no parent */
>if (strcmp(resource->uri, "/") == 0 ||
> -#ifdef WIN32
> -(strlen(ctx->pathname) == 3 && ctx->pathname[1] == ':' &&
>ctx->pathname[2] == '/')
> -#else
> -strcmp(ctx->pathname, "/") == 0
> -#endif
> - ) {
> +ap_os_is_path_absolute(ctx->pool, ctx->pathname)) {
Bad and wrong.
The former tested for "is this the root". ap_os_is_path_absolute() is not
the same test. The end result is that none of the resources will have
parents, which is going to *completely* break the lock tests.
>...
> @@ -1171,13 +1195,21 @@
>else {
> const char *dirpath;
> apr_finfo_t finfo;
> +apr_status_t rv;
>
> /* destination does not exist, but the parent directory should,
>* so try it
>*/
> dirpath = ap_make_dirstr_parent(dstinfo->pool, dstinfo->pathname);
> - if (apr_stat(&finfo, dirpath, APR_FINFO_NORM, dstinfo->pool) == 0
> - && finfo.device == srcinfo->finfo.device) {
> +/*
> + * XXX: If missing dev ... then what test?
> + * Really need a try and failover for those platforms.
> + *
> + */
> +rv = apr_stat(&finfo, dirpath, APR_FINFO_DEV, dstinfo->pool);
> + if ((rv == APR_SUCCESS || rv == APR_INCOMPLETE)
> +&& (finfo.valid & srcinfo->finfo.valid & APR_FINFO_DEV)
> + && (finfo.device == srcinfo->finfo.device)) {
> can_rename = 1;
If the device doesn't exist or doesn't match, then it just does a copy.
>...
> @@ -1868,11 +1900,11 @@
>{
>const dav_liveprop_spec *info;
>
> -#ifndef WIN32
> -/* this property is not usable (writable) on the Win32 platform */
> +/* XXX this property is not usable (writable) on all platforms
> + * Need an abstract way to determine this.
> + */
>if (propid == DAV_PROPID_FS_executable && !resource->collection)
> return 1;
> -#endif
This is a bad change. Unless/until you get the query, then you should not be
removing this check. You're now advertising a property as being present, but
is ineffectual.
There are clients out there today which know and handle this custom
property. You're breaking them.
>...
> @@ -2036,10 +2068,11 @@
>
>void dav_fs_gather_propsets(apr_array_header_t *uris)
>{
> -#ifndef WIN32
> +/* XXX: Need an abstract way to determine this on a per-filesystem basis
> + * This may change by uri (!) (think OSX HFS + unix mounts).
> + */
>*(const char **)apr_array_push(uris) =
>"";
> -#endif
>}
Same problem. The #ifndef should be restored unless/until you have the query
mechanism in place.
>...
> @@ -2077,16 +2110,8 @@
> what, phdr);
>(void) dav_fs_insert_prop(resource, DAV_PROPID_getetag,
> what, phdr);
> -
> -#ifndef WIN32
> -/*
> -** Note: this property is not defined on the Win32 platform.
> -** dav_fs_insert_prop() won't insert it, but we may as
> -** well not even call it.
> -*/
>(void) dav_fs_insert_prop(resource, DAV_PROPID_FS_executable,
> what, phdr);
> -#endif
And one more to put back.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
