Re: [PATCH] configurable Location block speed up

[Joshua Slive]

On Wed, 4 Feb 2004, [ISO-8859-15] André Malo wrote:

> * [EMAIL PROTECTED] wrote:
>
> > If there are sites out there that ignore the piece about the content living
> > outside the filesystem, my previous patch which requires no new
> > configuration might create problems.  This version adds an OutsideFilesystem
> > directive, only valid in , to eliminate the possibility for
> > unpleasant surprises when upgrading httpd.  It causes the directory walk to
> > be skipped if set.  btw, I'm thinking of this as a 2.1 thing which wouldn't
> > be backported.
>
> (without closer looking at the code)
> I'd suggest rather
>
> 
> 
>
> where the virtual keyword defines that the location is independent from
> filesystem.

Perhaps I'm misunderstanding the issue, but neither of these make sense to
me.  It is not really the behavior of the  block that is
changing.   always acts outside the filesystem.  What is
changing is that a certain directive inside a  block should be
applied differently.  So shouldn't this just be

SetVirtualHandler server-status
or
SetHandler virtual server-status

Joshua.

Re: FileSystem v.s. Other Resources [was configurable Location?]

[Joshua Slive]

I just want to add a couple notes here on what I see as user-expectations.

> > The problem is that you want to add layers of additional directives, which
> > would change the behavior of  or ,
>
> only , in a way that IMO is consistent with the existing
> documentation, but not the existing code of course.
[...]
> A complication to treating  as if it's outside the filesystem
> is the doc that states  is a quick way to apply a config to
> the whole server.  It will indeed do that today, unfortunately.  I
> believe another quick way to get the same result is to put your config
> directives outside of any container.  If that's true, I would prefer to
> see that doc for  removed.  If the change to the behavior of
>  is configurable, this is not an issue.  If it's not
> configurable, then we probably should treat  as if it's in
> the filesystem - a special case for backwards compatibility.

I wrote the particular doc you quoted earlier, and I meant it more as a
recommendation (for security reasons) than a documentation of how apache
works.  The true description of how apache is supposed to function is
here:

http://httpd.apache.org/docs-2.0/sections.html

(But it is a little vauge, because my knowledge of the internals of
configuration merging was not sufficient to clarify it the last time I
went through.)

Many people do, in fact, use  for filesystem-related things.
See the examples in the mod_dav docs for one:
http://httpd.apache.org/docs-2.0/mod/mod_dav.html

Although I don't think this is esthetically correct, it is not
particularly dangerous.  Using  to provide *extra* access is
okay, because if you circumvent the  using filesystem tricks,
you just lose the access.  Using  to *restrict* access is not
safe, because the restrictions may be circumvented.

The other important thing to note is that  is often used for a
reason that is particular to apache configuration merging:
those sections are evaluated last.  That means that

Order deny,allow
Deny from all
Allow from local.net

has a very different effect than the same directives placed in  because it will be evaluated after all  and 
sections which could potentially override directives.

I'm not saying that this is a strictly correct use of , but it
is very useful and there is no other easy way to accomplish this "apply
this directive after everything else" effect.

I do, however, agree that doing a directory-walk on virtual resources is
not nice.  But my opinion is that "virtualness" is a property of the
resource, and hence should be designated when selecting the resource.
That is why I suggested changing SetHandler rather than .

Joshua.

Re: FileSystem v.s. Other Resources [was configurable Location?]

[Joshua Slive]

> I do, however, agree that doing a directory-walk on virtual resources is
> not nice.  But my opinion is that "virtualness" is a property of the
> resource, and hence should be designated when selecting the resource.
> That is why I suggested changing SetHandler rather than .

And perhaps I'm going way off in left field here, but why should this be
user-configurable at all?  Shouldn't the (for example) server-status
handler know itself that it is a virtual handler, and therefore indicate
that the directory-walk should be skipped?

Joshua.

Re: How to get plain text responses from Apache and subdirectory contents

[Joshua Slive]

[This is probably a question better suited to [EMAIL PROTECTED]

On Sat, 7 Feb 2004, GEORGE JOSEPH wrote:
>   I am developing a client program which communicates
> with the Apache server to download files in its
> /var/www/html/media directory.
>
> I wish to get the Index listing of the above mentioned
> directory ,in plain text format.Is that possible?

Not from mod_autoindex.  See the mod_autoindex for the various formats it
supports; but all are some variation of html.

You may want to look at mod_dav, which provides some more structured (xml)
methods for finding information about resources.

Joshua.

Re: FileSystem v.s. Other Resources [was configurable Location?]

[Joshua Slive]

On Mon, 9 Feb 2004, Brian Akins wrote:
> 
>   SetHandler virtual-dynamic-handler
> 
>
> Alias /normal/stuff/dyn /dynamic-stuff
>
>
> How would all this affect this situation?  IE, we would still need to
> know that /normal/stuff/dyn/1/2/test.html became
> /dynamic-stuff/1/2/test.html

Alias maps URLs to the filesystem.  The second argument must be a
filesystem path, and should not be mapped against any .

Joshua.

Re: Patch for query string customization?

[Joshua Slive]

On Mon, 9 Feb 2004, Brett E. wrote:
> We recommend that HTTP server implementors, and in particular, CGI
> implementors support the use of ";" in place of "&" to save authors the
> trouble of escaping "&" characters in this manner.

> So maybe we should conform to the spec and support both styles.

Huh?  This has nothing to do with the character that marks the start of
query strings "?".  It is dealing with the character that delineates
variables within a query string ("&" or ";").  Apache doesn't care at all
about what comes after the "?", except in limitted cases like
mod_autoindex (which already uses the ";" delimiter rather than "&").

You should be looking at whatever program or module is interpreting the
query string.  The base apache code has nothing to do with it.

Joshua.

Re: [PROPOSAL] Move httpd to the subversion repository

[Joshua Slive]

On Sun, 14 Mar 2004, William A. Rowe, Jr. wrote:
> As I mentioned to the [EMAIL PROTECTED]'ers I would feel much safer moving 2.1-dev
> over to SVN (with APR 1.0) and leaving 2.0/apr 0.9 alone to the end of
> their useful life.

Ugh.  That sounds like it will make back-porting even more of a pain than
it already is, and would require two toolsets to be maintained.  In
essence, I think we would wind up getting all the costs of subversion
without most of the benefits (until all the old code is retired).

It sounds like there are some serious differences of opinion on this
issue.  Would it help to make the arguments a little more concrete?
I've made a start below.  I can commit to STATUS if you'd like.

I personally lean towards adoption of subversion.  I agree that keeping
barriers to entry as low as possible is crucial.  But I don't think that
subversion needs to be a serious problem there.


Advantages of moving to subversion:
- All the advantages over cvs as discussed at http://subversion.tigris.org/
  (How important are these for Apache?)
- Uses Apache 2 as transport, which has the benefits:
  - Dogfood
  - Don't need unix accounts for all committers (eventually)
  - Less problems with firewalls

Disadvantages of moving to subversion:
- Not as portable (?)
- New tool to install/learn
- Not integrated into as many IDEs
- Backups/integrity (fixable?)

Re: AddCharset filename extensions (again)

[Joshua Slive]

Question: Why are we involved in this at all?  Wouldn't people publishing
in these languages know much more about the relevant character sets and
the filename extensions that they want to use?  Can't we just remove all
of these from httpd.conf (except the ones necessary for the docs and the
welcome page (ick))?

Joshua.

RE: AddCharset filename extensions (again)

[Joshua Slive]

On Fri, 19 Mar 2004, Mathihalli, Madhusudan wrote:

> I guess it's just to give a good out-of-the-box experience !
>
> (Oh look - apache understands my language pretty nicely - that's neat :) )

But does anyone really use those languages with those particular
extensions?  Don't 99% of people just change the default language/charset?
And isn't the effort required to understand those directives and find the
right file extension about the same as the effort required to map your own
extension?

If people really use those things, then I'm fine with leaving them.  But I
suspect that they are just pointless httpd.conf bulk.

Joshua.

Re: mod_auth_digest and MSIE

[Joshua Slive]

On Fri, 19 Mar 2004, Edward Rudd wrote:

> I do have to question the *idea* of hacking an RFC compliant module to
> support non RFC behavior?  I know for Cyrus IMAP their stance is not to
> break with the RFC, but to have the consumers complain to the MUA
> creator to fix their bug.  Though this issue has been brought up to MS
> over a year ago, and they still refuse to fix it.
>
> Another question would be, IF the hack does make it's way in, I suggest
> that it should be wrapped around a big IF, so that a configuration
> directive must be enable to enable the hack. (similar to the
> mod_auth_ldap MSFrontPage hack)

The hack would only be in effect if teh AuthDigestEnableQueryStringHack
env variable was set (which could happen, for example, using a
BrowserMatch directive).

Joshua.

Win32DisableAcceptex

[Joshua Slive]

Didn't we decide in the move to 2.0 that all directives would take an
argument?  Win32DisableAcceptex seems to work just by being present in the
config with no argument.  Shouldn't it instead be
Win32DisableAcceptex on|off

Joshua.

Re: Win32DisableAcceptex

[Joshua Slive]

On Mon, 22 Mar 2004, Bill Stoddard wrote:

> Joshua Slive wrote:
> > Didn't we decide in the move to 2.0 that all directives would take an
> > argument?
> Maybe I wasn't paying attention.

As far as I know, there are no other directives in httpd-2.0 that act this
way.  But I may be mistaken.

> > Shouldn't it instead be Win32DisableAcceptex on|off
> To be more consistent with EnableSendFile on|off, et. al? Hadn't considered that but 
> it makes sense.

I guess then it should be
Win32EnableAcceptex on|off
with "on" the default.

But I guess I am too late for this discussion since we released it in
2.0.49 and changing it now would break compatibility.

Joshua.

Re: deflate input filter and jk

[Joshua Slive]

On Wed, 31 Mar 2004, Henri Gomez wrote:
> Also the Content-Length is set to the size of the
> plain request (not the size of the compressed request).
>
> Is it correct or should it send the Content-Length with
> the size of the compressed request ?
>
> In such case, it seems that mod_deflate INPUT filter should
> modify the Content-Length accordingly ?

The note at the bottom of this section:
http://httpd.apache.org/docs-2.0/mod/mod_deflate.html#enable
says that it should be the compressed length and that the server is not
responsible for changing the length during decompression.

Joshua.

Re: cvs commit: httpd-2.0/server core.c

[Joshua Slive]

On Thu, 8 Apr 2004, Geoffrey Young wrote:
> [EMAIL PROTECTED] wrote:
> > geoff   2004/04/08 17:56:26
> >
> >   Modified:.CHANGES
> >server   core.c
> >   Log:
> >   Enable special ErrorDocument value 'default' which restores the
> >   canned server response for the scope of the directive.
>
> if this stays in 2.1 it will need some docs.  I saw that the 2.1 docs are
> maintained in HEAD just as with the code, but I'm unsure of whether to edit
> the .xml, .html.en, or both.

Just edit the .xml.  (There is a big ugly note at the top of the .html.en
telling you not to touch it.)  Then you can build the .html.en using
the instructions here:
http://httpd.apache.org/docs-project/docsformat.html
Or if you don't want to bother, just do the .xml and someone else will
take care of building the .html.

Joshua.

Re: cvs commit: httpd-2.0/server core.c

[Joshua Slive]

On Sat, 10 Apr 2004 [EMAIL PROTECTED] wrote:

> nd  2004/04/10 14:44:43
>
>   Modified:.CHANGES
>server   core.c
>   Log:
>   accept URLs as ServerAdmin contact. If it's not recognized as an URL, assume
>   an email address and prepend it with mailto: in server outputs.

Careful with this, since I believe it also affects the SERVER_ADMIN env
variable.  The docs should warn that some scripts might depend on this
being an email address.

Joshua.

Re: [PATCH] Candidate 1: Re: 1.3.3x digest/nonce issue

[Joshua Slive]

I do have one question about this:  Is anyone actually using mod_digest?
I was under the impression that there doesn't exist any client that can
interoperate with this module (as opposed to mod_auth_digest, which
supports modern clients).  If this is true, why don't we just delete the
darn thing?

Joshua.

Re: cvs commit: httpd-docs-1.3/htdocs/manual/mod core.html.en mod_digest.html

[Joshua Slive]

On Thu, 15 Apr 2004 [EMAIL PROTECTED] wrote:
>MD5 authentication provides a more secure password system,
>but only works with supporting browsers. As of this writing
>   -(January 2002), the only major browsers which support digest
>   -authentication are http://www.opera.com/";>Opera 4.0,
>   -http://www.microsoft.com/windows/ie/";>MS Internet
>   -Explorer 5.0 and http://www.w3.org/Amaya/";>Amaya.
>   -Therefore, we do not recommend using this feature on a large
>   -Internet site. However, for personal and intra-net use, where
>   -browser users can be controlled, it is ideal.
>   +(December 2003), most major browsers support digest authentication.
>   +

Most browsers support digest, but I believe our conclusion is that at
least MSIE does not support the old version of the spec used by
mod_digest.  So this paragraph is not accurate.  It also conflicts with
what is written under "Summary".

Joshua.

Re: MultiViews

[Joshua Slive]

On Tue, 20 Apr 2004, Mooky Mooksgill wrote:

> I want to use MultiViews, as my pages have recently switched from .htm
> to .html
> I have turned on MultiViews for my VirtualHost, but eg, /about.htm
> doesn't serve the existing /about.html.
>
> Is this expected? When I ask for /about my about.html is served...
>
> I know there are other ways like rewrite or redirect, any others???
> but should MultiViews do this too?

Multiviews works only if no extension is specified.

You probably want

RedirectMatch ^/(.*)\.htm$ http://yourhost.example.com/$1.html

Joshua.

Re: WebDAV and reading / writing files as system users

[Joshua Slive]

On Thu, 29 Apr 2004, Graham Leggett wrote:
> The perchild mpm seems to be the closest thing to what I am looking for,
> but the manual warns that it is not functional. Is this still the case?

Yes.  I don't know of anyone successfully using perchild.  There is another
group working on a successor called something like mpmmux, but they've
been rather quite too.

> Can perchild support the idea of becoming a user specified via an auth
> module using something like basic authentication?

Not with its current design.  For one thing, it needs to have a pool of
child threads available for each possible user, which would make it rather
inappropriate for a large number of users.  For another thing, it
currently only supports different users on a per-vhost basis.   But I
suppose that last restriction would be easy enough to relax.

Joshua.

Re: WebDAV and reading / writing files as system users

[Joshua Slive]

On Fri, 30 Apr 2004, Graham Leggett wrote:
> But if this proper filesharing concept is to work properly, then at some
> point the DAV server will have to support some kind of interaction with
> the filesystem along far better lines than the current "one user owns all".

If you really want apache to behave like samba, then I suppose you don't
mind if apache runs as root.  Then it becomes rather more simple to do the
sort of things you are interested in.  It also becomes rather more simple
to compromise your box.

Joshua.

Re: Disabling TransmitFile() function

[Joshua Slive]

On Mon, 3 May 2004, Prasad Venkata Boddupalli wrote:
> I am building a message protocol on top of TCP for which I modified the
> WSASend() and its sister functions to attach a header to every packet and
> WSARecv() functions to recognize the header. Since I cannot do the same
> with the TransmitFile() and AcceptEx() functions, I need to disable them.
> I realized that the directive Win32DisableAcceptEx does the trick for
> AcceptEx() function. But, how can I disable TransmitFile() function and
> force the server to use regular WSASend() function?

EnableSendfile Off

Joshua.

Re: Apache 1.3.31 RC Tarballs available

[Joshua Slive]

The URL has been posted on slashdot :-(

Joshua.

Re: Apache 1.3.31 RC Tarballs available

[Joshua Slive]

On Fri, 7 May 2004, Aaron Bannert wrote:

> Why is it bad if people download the RC version and
> test it? Frankly, I really don't mind if slashdot or anyone
> else broadcasts that we have an RC tarball available.

The problem was that they called it a release, not an RC.  I added the
header.html to that directory to try to make it clearer what people were
downloading, but I think moving the tarball was appropriate given the
chance of people trusting the slashdot info and believing this was a real
release.

Joshua.

Re: looking for mpm-perchild info

[Joshua Slive]

On Thu, 20 May 2004, Binam, Jesse wrote:

> I apologize if this is the wrong forum. I saw in the documentation that
> the perchild mpm development has ceased. I have looked on apache.org for
> info but did not find anything. I am curious if anyone in here can tell
> me where else I might look for information on why it stopped, as I would
> like to investigate the possibility of giving it another go at life.

The only info you'll find will be in the archives to this list.

Its development stopped, I believe, because the only person working on it
seriously -- Ryan Bloom -- decided to do other things.

Some other people have been working on a similar project called something
like mpmmux.  But they have been pretty quiet lately too.

Joshua.

Re: looking for mpm-perchild info

[Joshua Slive]

On Thu, 20 May 2004, Sascha Kersken wrote:

> You might want to try metux MPM instead; it provides similar functionality
> and works all right: http://www.metux.de/mpm/


"metux"... That's the name I keep forgetting.

But you might note that your website is not very useful since the download
link is broken.

Joshua.

suexec hook ordering (was Re: seeking for a developer to commit a patch)

[Joshua Slive]

On Sun, 23 May 2004, Florian Effenberger wrote:
> I am seeking for a developer to commit a patch Joshua Slive kindly
> provided. Please have a look at
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=18156

The patch is simply changing the hook ordering of get_suexec_identity so
that UserDir users will override SuexecUserGroup users.  I believe this is
how it worked in 1.3, and it appears that the intention was to make it
work the same way in 2.0.

The patch is obvious enough, but I'm not in a position to test suexec.
For anyone who can do a quick check on suexec, this should be an easy
patch.

Joshua.

RE: Reload CRL without re-starting Apache

[Joshua Slive]

On Tue, 25 May 2004, Mathihalli, Madhusudan wrote:
I have a patch that achieves the purpose - but it's more of a hack. I'm
looking for suggestions to clean it up.
Here's the current logic :
- user invokes "apachectl updatecrl" which sends a SIGUSR2 signal to the
parent process
Question from an innocent bystander: Is there some reason that "apachectl 
graceful" isn't good enough for this situation?

Joshua.

RE: Reload CRL without re-starting Apache

[Joshua Slive]

On Tue, 25 May 2004, Mathihalli, Madhusudan wrote:
Here's the current logic :
- user invokes "apachectl updatecrl" which sends a SIGUSR2 signal to
the parent process
Question from an innocent bystander: Is there some reason that
"apachectl
graceful" isn't good enough for this situation?
AIUI, the 'graceful' restart forces the child processes join all the
threads and re-start. (Pl. let me know if this is incorrect).
The requirement is to update the crl without causing the process to
re-start in order to achieve a zero down-time.
Yes, the "graceful" restart does force all the child process/threads to 
restart.  But it does so in a "graceful" manner: workers are not killed 
until they are done serving requests and new workers are started before 
the old ones are killed in order to assure that there is always a pool of 
workers available to serve new connections.

Theoretically, "apachectl graceful" should have zero down-time from the 
client perspective.

Of course, this recycling will cause some extra load on the server, so 
having a method of reloading arbitrary parts of the configuration is not a 
bad idea.  But whether it is worth the effort over a nice, clean 
"apachectl graceful", I couldn't say.

Joshua.

Re: Better error logging for mod_access

[Joshua Slive]

On Sat, 5 Jun 2004, Jeff Trawick wrote:

> [EMAIL PROTECTED] wrote:
>
> > The patch here:  for
> > 2.0.49 creates logs that look like this:
> >
> > [Fri May 28 22:19:16 2004] [notice] Apache/2.0.49 (Unix) configured --
> > resuming
> > normal operations
> > [Fri May 28 22:19:24 2004] [error] [client 192.168.1.33] client denied by
> > order directive at line 362 of /opt/apache2/conf/httpd.conf for:
> > /opt/apache2/htdocs/bar
>
> What about enabling via a per-dir directive?  Looks very useful, but some sites
>   might have a significant number of new entries in error log serving no useful
> purpose (for them).

The problem with per-dir is that the user might not know exactly where in
the config file he should be editting.  If they did, they probably
wouldn't have a problem finding the relevant allow/deny in the first
place.

What about keeping the old error message, but logging an *additional*
message at loglevel debug with the additional info?

Two other notes:
- Personally, I hate arbitrary path-size limitations.  They always bite
you when you least expect it.  What about dynamically sizing this?
- You'll get more people to read your patches if you use "diff -u".

Joshua.

Re: Better error logging for mod_access

[Joshua Slive]

On Sat, 5 Jun 2004, Rici Lake wrote:
> > What about keeping the old error message, but logging an *additional*
> > message at loglevel debug with the additional info?
>
> That is certainly possible but I was trying to make things as easy as possible
> for newbies. I think having both modules available, and using a -D flag to
> select which one to load would probably work out better. But that is just one
> person's opinion.

I can say with relative certainty that you won't get people to agree to
that solution.  It involves a bunch of new complexity (distributing and
compiling two almost-identical modules) for one new debugging feature.
Opening httpd.conf and finding the LogLevel directive, which appears only
once, should be relatively easy.

> > - You'll get more people to read your patches if you use "diff -u".
>
> Tastes vary.

Yes, tastes vary.  But Apache has a "defined" taste:
http://httpd.apache.org/dev/patches.html

Joshua.

Re: [PATCH] event driven MPM

[Joshua Slive]

On Tue, 8 Jun 2004, Greg Ames wrote:
There are sites/workloads where keepalive timeouts tie up the majority of the
active threads or processes, such as our own web site as seen at
http://apache.org/server-status .  I also see a lot of "K"s when running 
specweb99 on a stock httpd.  Since we are between requests during keepalive 
waits, they can be handled differently without impacting a lot of code.
I don't have any technical comments, other than "cool".  But I can confirm 
that many people report needing to turn KeepAlive off to get reasonable 
performance from apache.  It might be interesting to see the KeepAlive off 
case along-side the current implementation and the event-drive 
implementation in benchmarking in order to prove that this really wins.

Joshua.

Re: [PATCH] event driven MPM

[Joshua Slive]

On Tue, 8 Jun 2004, Bill Stoddard wrote:

> Joshua Slive wrote:
> > I don't have any technical comments, other than "cool".  But I can
> > confirm that many people report needing to turn KeepAlive off to get
> > reasonable performance from apache.
>
> Joshua, Tell us more. If you can't start enough processes/threads to
> handle the number of incoming connections, then setting keepalivetimeout
> from 15 to 5 seconds or turning off keepalive entirely will boost the
> apparent number of 'concurrent' connections able to be handled by the
> server. I've found this useful in several customer cases I've worked on.
> The eventdriven patch should solve this problem quite handily.

Yes, that is what I meant.  People with limited memory (so they can't
just up MaxClients) can sometimes serve many more "people" by turning off
keepalive in order to free slots.  With this patch, they should get the
best of both worlds (keepalive plus all worker threads handling actual
content).

Joshua.

Re: Does anyone know how to get Apache 20 to do HTTP 1.0 vs.. HTTP 1.1?

[Joshua Slive]

On Tue, 15 Jun 2004, Avery, Ken wrote:
Does anyone know if it is possible to tell/negotiate with Apache 2.0 to
handle requests as HTTP 1.0 instead of HTTP 1.1?
This seems more like a users-list question, but...
Apache automatically uses HTTP/1.0 with HTTP/1.0 clients.  If you want it 
to speak HTTP/1.0 all the time, you use
SetEnv downgrade-1.0 force-response-1.0

See:
http://httpd.apache.org/docs-2.0/env.html#special
Joshua.

RE: I'd like to make some contributions

[Joshua Slive]

On Thu, 17 Jun 2004, Guernsey, Byron (GE Consumer & Industrial) wrote:
Don't expect a quick response.  I submitted a feature patch to bugzilla 
over a month ago and it hasn't changed state from its "new" state or had 
any activity or ownership changes.  I posted a followup message here a 
few weeks later and have not received a single response.  I continue to 
read messages here to see if this process described in the below URL 
actually works or if I just need to maintain separate patches for the 
version we use at GE indefinitely- something I don't want to do...

Details how code patches should be submitted are described at
http://httpd.apache.org/dev/patches.html
Perhaps this page needs a section entitled "What to do if my patch gets 
ignored".  It could go something like this:

Because Apache has only a small number of volunteer developers, and these 
developers are often very busy, it is possible that your patch will not 
receive any immediate feedback.  Here are some suggestions on what you can 
do in this case:

1. Encourage other Apache users to review and test your patch, and then 
append a note to the bug report with the details.  Developers are much 
more likely to review and commit a patch if they see that it has been 
widely tested.

2. Post to the developers list with the bug number included as specified 
above, pointing out your patch and why you feel it is important.  Feel 
free to do this about once a week and continue until you get a response. 
Just be sure to be polite about it, since the developers are unlikely to 
respond to rude messages.

Joshua.

Re: apachectl script enhancement

[Joshua Slive]

On Mon, 28 Jun 2004, Jim Jagielski wrote:
Anyone have any problem if we enhance apachectl a bit to allow
for -v/-V printout? Like ./apachectl version | ./apachectl fullversion ?
I don't understand.  "apachectl -v" and "apachectl -V" work fine. 
(apachectl passess unknown parameters directly to httpd.)

Joshua.

Re: Question/Proposal concerning the Apache download page

[Joshua Slive]

On Thu, 1 Jul 2004, Sascha Kersken wrote:

> Hi all,
>
> wouldn't it be a nice idea to make the http://httpd.apache.org/download.cgi
> script accept the name of the requested file (e.g. httpd-2.0.50.tar.gz) as
> path info and pass it to the automatically selected mirror? This would allow
> everyone to link to any specific download file without having to choose a
> single mirror in advance.

There is another script (with the same back-end) that does almost this.
See, for example:
http://www.apache.org/dyn/closer.cgi/httpd/httpd-2.0.50.tar.gz

This presents a list rather than directing you to a single mirror.  The
problems with just sending a redirect are: 1. you have no alternatives if
the mirror happens to be bad, and 2. it is not clear enough that the
download is coming from a mirror, not apache.org.  (Our mirrors are not
trusted, so it is important that people realize they are using a mirror
and must check signatures against the apache.org site.)

Joshua.

Re: Question/Proposal concerning the Apache download page

[Joshua Slive]

On Thu, 1 Jul 2004, Astrid Keßler wrote:

> > There is another script (with the same back-end) that does almost this.
> > See, for example:
> > http://www.apache.org/dyn/closer.cgi/httpd/httpd-2.0.50.tar.gz
>
> Cool. Is this script linked somewhere? Or there any description out
> there at our site?

This is the script you'll get if you choose "Download" from the
www.apache.org site, but it doesn't use the fancy PATH_INFO from there.

It is (briefly) documented here:
http://www.apache.org/dev/mirrors.html

Joshua.

Re: Where do historical httpd binaries go?

[Joshua Slive]

On Fri, 2 Jul 2004, Graham Leggett wrote:
Hi all,
Where do historical binaries get moved to (if anywhere)?
http://archives.apache.org/dist/httpd/binaries/
Joshua.

Re: Where do historical httpd binaries go?

[Joshua Slive]

On Fri, 2 Jul 2004, Joshua Slive wrote:
On Fri, 2 Jul 2004, Graham Leggett wrote:
Hi all,
Where do historical binaries get moved to (if anywhere)?
http://archives.apache.org/dist/httpd/binaries/
Ahhh Make that
http://archive.apache.org/dist/httpd/binaries/
And note that the "moving" is automatic: everything from 
www.apache.org/dist/ goes there automatically, and nothing is ever
deleted.

Joshua.

Re: Where do historical httpd binaries go?

[Joshua Slive]

On Fri, 2 Jul 2004, Graham Leggett wrote:
And note that the "moving" is automatic: everything from 
www.apache.org/dist/ goes there automatically, and nothing is ever
deleted.
Automatic as in "a script does it"? I just moved the old release I was 
replacing manually from www.apache.org/dist/httpd/binaries/linux to 
archive.apache.org/dist/httpd/binaries/linux/old. Should I have left it?
Yes.  There is really no need to move stuff around.  As files are added 
and deleted from www.apache.org, they will just accumulate in whatever 
directory in the archives.

Joshua.

Re: PROPOSAL: Enhance mod_headers as a debug/test tool

[Joshua Slive]

On Sun, 4 Jul 2004, [ISO-8859-15] André Malo wrote:
> > My proposal is to introduce an additional DEBUG keyword to the
> > Header and RequestHeader directives.  Headers marked as DEBUG will
> > be set in post_read_request, so they are available to other modules.
> > Without DEBUG, it will default to current (fixups) behaviour.
> >
> > Of course, DEBUG won't work with conditional (Request)Header directives.
> > In addition to documenting this, attempts to do so will log a warning.
>
> Sounds like a good tool. comments from me:
>
> - I would not call it DEBUG, but "early" or "setearly" or the like

I agree. Note that if you add this, people will use it for things other
than debugging.  For example, there are frequently requests to do silly
things like ignore the client's Accept header.

> - I'd just replace the env clause with that keyword (i.e. mutual exlusion)
> - post_read_request is *really* early. So these directives would be only valid
> in server context / virtual host.

Of course, for these reasons, people won't be able to do as much mangling
as they want.  So this feature would need to be carefully documented.

Joshua.

Re: Apache 2.0.50 mod_ssl

[Joshua Slive]

On Sun, 4 Jul 2004, Kenneth Simpson wrote:
> mod_ssl doesn't change when upgrading from Apache 2.0.49 to Apache 2.0.50.

This would happen if you had mod_ssl installed as a DSO but didn't specify
--enable-ssl=shared on the ./configure command line when upgrading.  The
old module would remain.

Joshua.

Re: The Byterange filter -- a new design -- feel free to rip it to shreds

[Joshua Slive]

On Tue, 13 Jul 2004, Joe Orton wrote:
I'm beginning to think the only sane way to fix the byterange filter is
to have it do nothing if it isn't passed a complete EOS-terminated
brigade with a predetermined length, i.e. no morphing CGI buckets which
will eat all your RAM when they get ->read().
Being able to send byteranges of arbitrary dynamically generated content
doesn't seem like an essential feature; the filter is just saying "I
can't efficiently process a byterange request for this content".
Clients must handle the 200 response fallback already.
I'd tend to agree with this.  But as long as the byte-ranges are in-order 
and not-overlapping, the byterange filter should still be able to handle 
the request without buffering anything.  I couldn't tell you what 
percentage of byterange requests are like this (I've heard that Acrobat 
uses out-of-order ranges), but it should handle many simple cases.

Joshua.

Re: Apache 2 and EBCDIC doc

[Joshua Slive]

On Wed, 14 Jul 2004, Henri Gomez wrote:
Hi,
In Platform Specific Notes for EBCDIC, 
http://httpd.apache.org/docs-2.0/platform/ebcdic.html,
it could be worth to mentions another EBCDIC platform who
support and use Apache 2.0, iSeries (AS/400).

Also in the Third Party Modules' Status, you could add mod_jk
1.2.x which works on both BS2000 and iSeries.
As far as I know, that document is total garbage.  It hasn't had any 
updates since 1.3 and doesn't reflect the current state of EBCDIC.

Joshua.

Re: mod_cache: allowing urls ending in "/" to be cached

[Joshua Slive]

On Fri, 16 Jul 2004, Graham Leggett wrote:
Pier Fumagalli wrote:
I don't understand why mod_cache forcedly avoids caching URLs ending with 
the "/" (slash) character.

Apparently EGP (who's he?) agrees.
Anyhow, it's several months that we're running with this patch in 
production, and nothing bad seems to be happening.
If it works, I say commit the patch. Can think of no reason why we should not 
cache an URL ending is /.
+1 (untested).  This has been discussed here several times, and if I 
recall correctly, the only comment was that index files may be subject to 
negotiation.  But that's not a good argument, since *any* file may be 
subject to negotiation.

Joshua.

Re: Invitation to HTTPD commiters in tomcat-dev

[Joshua Slive]

Graham Leggett wrote:
The "httpd serves the static content" feature can be implemented through 
extending ProxyPass to support regular expressions, for example:
This can be done now with mod_rewrite:
RewriteRule (.*\.jsp)$ http://backend/$1 [P]
Joshua.

Re: Connection reset by peer errors in 2.0.50

[Joshua Slive]

On Tue, 27 Jul 2004, Dan Wilga wrote:
[Fri Jul 02 11:14:30 2004] [info] Initial (No.1) HTTPS request received for 
child 0 (server [server name]:443)
[Fri Jul 02 11:14:30 2004] [info] (104)Connection reset by peer: 
core_output_filter: writing data to the network
[Fri Jul 02 11:14:30 2004] [error] 5894: ModPerl::Registry: Software caused 
connection abort at [path to script and line number].\n
[Fri Jul 02 11:14:30 2004] [error] 5894: ModPerl::Registry: Software caused 
connection abort at [path to script and line number].\n

If you have ideas about the possible cause of this problem, I can privately 
email you an error log of the SSL session produced with "LogLevel debug". I 
can also send you the environment variables at the time of the error.
I don't really understand what the problem is.  The "Connection reset by 
peer" is a perfectly normal condition resulting from -- as you've already 
figured out -- the client going away in the middle of the response.  The 
only thing that I see wrong here is that your mod_perl stuff is generating 
a message at loglevel "error" which is really not an error condition. 
You'd probably need to address that on the mod_perl list.

Is there some particular problem you are seeing other than just the 
existence of the error messages?

Joshua.

Re: [PATCH] mod_disk cached fixed

[Joshua Slive]

On Wed, 4 Aug 2004, Justin Erenkrantz wrote:
--On Wednesday, August 4, 2004 4:52 PM -0400 Brian Akins 
<[EMAIL PROTECTED]> wrote:
The thing that sucks is if you vary on User-Agent.  You wind up with a ton
of entries per uri.  I cheated in another modules by "varying" on an
environmental variable.  Kind of like this:
BrowserMatch ".*MSIE [1-3]|MSIE [1-5].*Mac.*|^Mozilla/[1-4].*Nav" no-gzip
and just "vary" on no-gzip (1 or 0), but this may be hard to do just using
headers...
Note that BrowserMatch with regexp's is ridiculously expensive.  Minimizing 
the need for that would be goodness, I think.  -- justin
But it couldn't be as expensive as caching a variant for every User-Agent 
that accesses your site.  What is probably needed is
CacheVaryOn env-variable
which would override the vary-matching decision to vary only 
on the content of env-variable (which could be just on/off in this case), 
but not touch the actual Vary: header, since down-stream caches wouldn't 
have the extra logic needed determine if they needed to vary.

Joshua.

Re: proxy enabled apache1.3.31

[Joshua Slive]

On Tue, 10 Aug 2004, g g wrote:
> I am trying to install apache 1.3.31 with proxy module enabled. I am
> using following option to configure the apache 1.3.31 on aix 5.1 m/c:
>
> ./configure --prefix= --enable-module=so
> --enable-module=proxy
>
> After installation there is no LoadModule directive for mod_proxy in
> httpd.conf. Also there is no mod_proxy.so file under apache
> installation.

This question should be directed to the [EMAIL PROTECTED] mailing
list, not the dev list.

(Hint: mod_proxy is statically compiled in the above configure command.
You'll see it with httpd -l.)

Joshua.

Re: httpd-2.2 release roadmap v0.1

[Joshua Slive]

On Thu, 12 Aug 2004, Jim Jagielski wrote:
Geoffrey Young wrote:
so, can someone comment on what 2.2 (and the subsequent 2.3) mean for 2.0?
that is, if everyday hacking is against 2.3 and we propose a new feature to
backport, do we backport to both 2.2 and 2.0?  or does it mean that 2.0 has
reached end-of-life and we backport only to 2.2?
just so I (and others) know what to expect... :)
I would foresee only 1.3 and 2.2 being around and 2.0 being EOLed.
I would hope we could make a statement like: "Major security issues will 
be addressed in 2.0 until at least [2.2 release date + 1 year]."

Joshua.

RE: Increasing LimitRequestFieldsize

[Joshua Slive]

On Sun, 15 Aug 2004, Justin Erenkrantz wrote:
--On Sunday, August 15, 2004 7:30 PM -0700 "Mathihalli, Madhusudan" 
<[EMAIL PROTECTED]> wrote:

I thought the 8K limit was a compile-time constant.

8190 is just our default.  HTH.  -- justin
But note that you can't raise it from the config-file default without 
recompiling to change the compile-time default 
(DEFAULT_LIMIT_REQUEST_FIELDSIZE) which is also 8k.

It might make sense to increase the compile-time default while retaining 
8k as the config-file default.  (But this would probably require changing 
the name of the constant to avoid confusing people.)

Joshua.

Re: mod_deflate and no-gzip

[Joshua Slive]

On Wed, 18 Aug 2004, Brian Akins wrote:
Shouldn't we still set "Vary: Accept-Encoding" if no-gzip is set?  Example, 
if I use SetEnvIf to disallow gzip for some browsers, shouldn't we still tell 
proxies to vary on "Accept-Encoding"?  mod_deflate will send the Vary if the 
client does not have a proper Accept-Encoding header, but not if we set 
no-gzip.  THis seems broken.  If mod_deflate is called, if should send a 
Vary.
What about
SetEnvIf Request_URI file[0-9]+\.html no-gzip
This doesn't require a Vary-header.  And in fact, the example you site 
requires a "Vary: User-Agent", not "Vary: Accept-Encoding".

This is a rather difficult problem, and I don't have a good solution to 
propose.  Currently, it is the responsibility of the admin to deal with 
Vary if they use no-gzip.  For an example, see
http://httpd.apache.org/docs-2.0/mod/mod_deflate.html#recommended
and for a discussion:
http://httpd.apache.org/docs-2.0/mod/mod_deflate.html#proxies

Joshua.

Re: cvs commit: httpd-2.0/docs/manual/programs configure.xml

[Joshua Slive]

On Fri, 20 Aug 2004 [EMAIL PROTECTED] wrote:
  --enable-auth-ldap
I suspect the above line needs to be changed too.
  Enable LDAP based authentication provided by
 -  mod_auth_ldap.
 +  mod_authnz_ldap.
Joshua.

Re: Bugzilla Requests

[Joshua Slive]

On Mon, 30 Aug 2004, Paul Querna wrote:
1) Upgrade Bugzilla a newer version.  We currently have 2.14.2
installed.  2.16.6 is the latest stable release of Bugzilla (They are
doing Release Canidates of 2.18.X right now too!).  It has nice things,
like a NEEDINFO state, so we can mark bugs that need feedback as such,
instead of leaving them as NEW.  This is a critical problem with the
current bugzilla. Hundreds of bugs are left in the NEW state when we are
waiting for Feedback.  This needs to be changed, even if we cannot
upgrade Bugzilla.
The current bugzilla install is falling apart.  It needs to be completely 
redone on a new machine.  There is some hope that the spamassassin people 
might help with this, since they are bugzilla experts.  But we also need 
to have a new machine for it.

In short, this is a known problem, but it is not going to be solved 
quickly because it is complicated.

As far as NEEDINFO, we can add a NEEDINFO keywork if you want.  That would 
get almost the same effect.

2) Add More Components to Bugzilla.  Here is my list of components I
would like to see added for our Project:
 - Windows Installer
 - Windows Build
 - mod_disk_cache
 - Default Configuration (Lots of requests for Add XXX Language or
comment  out in the Default httpd.conf)
 - Apache Bench / ab
I have the rights to do this.  I'll try to get to it soon.
3) Rename Some Components to be have a consistant naming style:
 - worker -> mpm_worker
 - prefork -> mpm_prefork
 - perchild -> mpm_perchild
 - support -> Support Utilities
 - Build -> Unix Build
This is rather difficult to do in bugzilla, I believe.
Joshua.

Re: Bugzilla Requests

[Joshua Slive]

Thinking about this a little more...
2) Add More Components to Bugzilla.  Here is my list of components I
would like to see added for our Project:
 - Windows Installer
 - Windows Build
Are these really necessary?  We have a "build" category already, and we 
could have a similar "install" category.  Then you could look in the OS 
field to see if it was for windows.  (Not quite as convenient, but much 
cleaner than duplicating a bunch of stuff across differents OSes.)

 - mod_disk_cache
Sure.
 - Default Configuration (Lots of requests for Add XXX Language or
comment  out in the Default httpd.conf)
We already have a "Runtime Config" category which is meant for exactly 
this.  Perhaps it is not used as much as it should be.

 - Apache Bench / ab
Are there enough bugs here to justify separating it out from "support"?
Joshua.

Re: Programming a timeout into Apache

[Joshua Slive]

On Tue, 31 Aug 2004, Wallace, Brian S. wrote:
Are there any tricks that can be done like telling the browser to clear
the password cache or have the browser return the realm name that it's
authenticating to?  Any other ideas or approaches to this problem would
be appreciated.
The are many tricks depending on the specific version of the specific 
browser.

There is no way that I know of to reliably instruct browsers to forget a 
password. A google search will find many discussions of this topic.

If you need to provide a reliable logout, you need to role your own 
sessions using that broken thing we call cookies or some other session 
technique.

Further discussion should go to [EMAIL PROTECTED]
Joshua.

Re: Shorten the default config and the distribution (was: IfModule in the Default Config)

[Joshua Slive]

On Tue, 14 Sep 2004, [ISO-8859-15] André Malo wrote:
A >30 KB default config, which nobody outside this circle here
really understands, isn't helpful - especially for beginners.
I agree that the current config file is too big and ugly.  But let's be a 
little careful here.  There needs to be a balance.  Detailed config files 
do help users understand the capabilities of the server and make it much 
easier to activate features.

So I suggest we talk about specifics, rather than just trying to reduce 
the size.  For example:

- Can we get rid of the non-unix mpm stuff from the default config. 
(Don't mean to offend os/2 and beos (and possibly netware), but they are 
really superfluous and confusing for most people.)

- Can we get rid of most of the AddLanguage/AddCharset directives?  They 
are a constant source of bug reports, and I really can't imagine that many 
people use them as-is.  (Do people really name their files 
index.html.utf32be.el?)

The above two changes alone would get rid of almost 200 lines.
In the same cycle we could remove the docs from the default distribution and
start distributing them officially as separate packages. (But we could
distribute a separate config snippet for the multilingual docs, which can
be included in the httpd.conf). The more translations we add, the less
applicable is it to include the whole doc tree.
+1
Joshua.

Re: Shorten the default config and the distribution (was: IfModule in the Default Config)

[Joshua Slive]

On Tue, 14 Sep 2004, Manoj Kasichainula wrote:
How about separating the "example" and "default" configs? Make the default 
config short, but provide an example config with all the meat that can be 
easily cut-and-pasted.
Or put richer examples in the docs.  We have been working on that a 
little.  Some of the module docs now come with a nice example config at 
the top which can be cut-pasted into httpd.conf (see 
mod_dav/mod_cache/mod_proxy/mod_defalte for examples).

For example, I think  lines in a config file are usually a bad 
idea, since the webserver should complain loudly if a needed module isn't 
present, instead of just ignoring the situation.
I've always been a strong supporter of that argument.  I frequently see 
people on the users list who try a directive and find that it doesn't work 
and they get no error message.  If they removed the  they would 
get a nice message telling them why it didn't work.

But there are several people who have argued strongly that they want the 
default config to work regardless of what modules people include in their 
build.

+1 to your proposal in the meantime (given my proposal above). I'd probably 
just get rid of all of the per-mpm stuff even. The mpms should have 
reasonable default values, so unless the admin needs to make a specific 
change, there should be no need for any of those directives in the default 
config.
+1!
If any changes in the defaults are necessary, then this would need to be 
2.1 only.  But I guess we are mostly talking about 2.1 in general anyway.

Joshua.

Re: Shorten the default config and the distribution (was: IfModule in the Default Config)

[Joshua Slive]

On Tue, 14 Sep 2004, William A. Rowe, Jr. wrote:
I'm trying to understand what other anomalies you mean between
Unix and Win32, they aren't that dis-similar.
I was mainly refering to the big block of mpm-control directives near the 
top.

But I like the suggestion of getting rid of almost all of that (besides 
some basic things like MaxClients) and not discriminating against non-unix 
mpms.

We have httpd-std.conf.in and ssl-std.conf.in, why not break
some of these more lengthy 'passages' into their very own
includes?  First and foremost, httpd-intl.conf.in - this
would take tons of lines across and leave a couple lines
Honestly, I prefer the one-config format, because I think it is easier for 
the new user to find what is going on if they know everything is in one 
file.  But this is a situation where personal preferences will vary.

But I have a compromise suggestion (based on Manoj's idea).  What about a 
conf/examples/ directory that would contain a bunch of little files with 
config snipets (like international.conf.in, proxy.conf.in, 
vhosts.conf.in).  Given the name of the directory, I would expect people 
to either copy-paste the stuff in httpd.conf or move the file before 
Include'ing it.  I wouldn't provide commented-out Include directives for 
these files.

Joshua.

Re: [VOTE] Apache HTTP Server 2.0.51

[Joshua Slive]

On Wed, 15 Sep 2004, Thom May wrote:
* Sander Striker ([EMAIL PROTECTED]) wrote :
Hi,
I've put the tarballs for 2.0.51 up at http://httpd.apache.org/dev/dist/.
Please test and vote,
+1 on x86_64 linux. (Worker and prefork. perchild built but not tested)
+1
Running on ajax.apache.org (www.eu.apache.org), which is ia64 Linux.
Joshua.

Re: [VOTE] Apache HTTP Server 2.0.51

[Joshua Slive]

On Wed, 15 Sep 2004, Sander Striker wrote:
From: "Sander Striker" <[EMAIL PROTECTED]>
Sent: Wednesday, September 15, 2004 4:49 PM

Thanks.  I've moved the tarballs to the distribution area.
Could someone please take care of the httpd.apache.org site?
I'm in a bit of a bind currently (for at least another 1-2 hours).
Done.
Joshua.

new config organization for 2.1

[Joshua Slive]

A straw-man proposal for a new config organization is at
http://www.apache.org/~slive/newconf/
What I've tried to do:
- Strip httpd.conf to only the config directives that almost everyone 
needs to worry about.

- Put everything else in an extra/ directory, with commented-out Include 
directives at the bottom of httpd.conf.

Some notes:
- This assumes that we have reasonable defaults for things like the 
mpm-related directives, since they will not be included by default in 
httpd.conf.

- The "It works" page would not work here, because none the international 
stuff is in the default config.  I consider this an advantage.  The "It 
works" page should be scaled back to a one-file one-liner (perhaps 
literally, It Worked!).

- I've removed the  directives for two modules: mod_mime and 
mod_dir.  These are essentially mandatory modules.  Anyone who decides not 
to use them better know enough to change their config.  Many other 
 directives become unnecessary because the configs are not 
active by default anymore.

- I'm still not a huge fan of the multiple-config-file setup.  But at 
least this way, there is only one file active by default.  Since user 
action is required to add other files, they should at least have some idea 
what is going on.

- Obviously this is a just a quick sketch.  It will require lots of 
comment changes and fine-tuning if we want to go in this direction.

Joshua.

Re: new config organization for 2.1

[Joshua Slive]

On Fri, 24 Sep 2004, William A. Rowe, Jr. wrote:
At 01:08 PM 9/24/2004, Paul Querna wrote:
On Fri, 2004-09-24 at 13:12 -0400, Joshua Slive wrote:
A straw-man proposal for a new config organization is at
http://www.apache.org/~slive/newconf/
Looks pretty good.  I think this is a good direction to move.
Any reason the Netware MPM part cannot be removed from near the top?
Don't pidfile, user and group directives belong in the mpm conf?
My idea is to put into httpd.conf all the directives that a "typical" user 
needs to look at when configuring a very basic apache, so I'm not grouping 
strictly by module.  I believe that PidFile and User/Group fall in that 
category.  (They shouldn't need to change PidFile, but they need to know 
where it is.)

I also think I will probably put a commented-out MaxClients (and 
equivalent win32/netware) directive back in httpd.conf, since that is 
another important mpm-related directive that everyone needs to know about.

Joshua.

Re: new config organization for 2.1

[Joshua Slive]

On Fri, 24 Sep 2004, Brad Nicholes wrote:
  Maybe I am jumping in here out of turn, but let me ask the obvious
question.  Why would we want to split the standard base httpd.conf file
up into multiple files?  Doesn't this end up just confusing the average
user?  One thing that I always tell new users of Apache is that rather
than trying to understand the entire alpabetical list of directives in
the httpd docs, go read the comments in the standard httpd.conf file.
This gives them a good idea of what the base set of directives are and
how they are used in a working context.  For newbies reading a single
.conf file seems easier to understand than trying to trace through
multiple .conf files just to figure out the big picture.  For those that
are Apache experts, they have already rewritten and rearchitected the
the httpd.conf file to fit their needs so they don't care.  I can
understand splitting dead or rarely used directives out, but it seems
much easier to read as a single file.  Maybe just some additional
formatting and comments to distinguish MPM directives from Language from
Vhosts, etc. is needed.
I agree entirely with the main sentiment.  The idea here is not to create 
a multi-file mess, but instead to create a much simpler httpd.conf that 
contains only the stuff that users really need.  That is the only config 
file that will be active by default, and the only one new users need to 
read at the start.

But then users who need more advanced stuff---or who simply want to 
explore the capabilities of apache---need to have good examples too. 
Those examples are kept in separate config files in a separate directory. 
I provided commented-out Include directives, but users who prefer can 
simply copy the examples directly into httpd.conf.

I guess my fundemental disagreement with you is that I don't believe that 
the current httpd.conf is salvagable by adding more comments or structure. 
The comments in that file are already quite verbose, and the file is just 
too darn long and complicated to be easily digested.  If you can suggest a 
better compromise solution, I am very interested.

Joshua.

Re: Version 2.0.52 Announcement text

[Joshua Slive]

On Mon, 27 Sep 2004, William A. Rowe, Jr. wrote:
Comments anyone?
Seeing all +1's and no objections, I'm planning to push this out
in the next hour or two.
The ?update argument to download.cgi should be changed to the date/time 
that you drop the files into dist/httpd/.  And you should try to wait some 
time between that drop and the announcement to give the mirrors an honest 
chance.

Joshua.

Bye bye welcome page

[Joshua Slive]

Fair warning:
As the first stage of a simplification of the default config in 2.1 
(only!), I'm going to remove all the html files under 
httpd-2.1/docs/docroot/ and replace them with an index.html file 
containing only It works!

I'm going to do this because:
1. The old welcome page is a constant source of confusion to random web 
surfers who stumble on unconfigured apache installs.

2. New users, when finding on a docroot with dozens of files, are often 
confused about where to put their own content.

3. The international welcome page is a large source of bug reports from 
people wanting to tweak grammar or provide new translations.

4. This will allow us to simplify the default config by removing the 
config stuff necessary to handle the typemap.

I'll wait until tomorrow uncase someone cares to object.
Joshua.

Re: Bye bye welcome page

[Joshua Slive]

On Tue, 5 Oct 2004, Graham Leggett wrote:
Joshua Slive wrote:
As the first stage of a simplification of the default config in 2.1 
(only!), I'm going to remove all the html files under 
httpd-2.1/docs/docroot/ and replace them with an index.html file containing 
only It works!
Is it possible to say a little bit more than just "it works"? Maybe something 
like "The webserver installation is successful, and the websrver is currently 
running. To host your own content, please replace this file with your website 
content and reload this URL in your browser."

The idea is that it says enough to give the user assurance that the server is 
working, but at the same time addresses your concerns of comebacks to us. 
Thoughts?
No, because this is a very confusing and ambiguous statement from the 
perspective of a random web surfer who stumbles on the page.  Their 
response is "Why are you saying I installed a webserver on my computer? 
This must be some kind of security breach.  Call in the marines!"  (And 
I'm hardly exagerating!)

In fact, your suggested text is very similar to the original (apache 1.1) 
welcome page:
http://cvs.apache.org/viewcvs.cgi/apache-1.3/htdocs/Attic/index.html?rev=1.1

The revisions since then have improved the situation somewhat, but my 
guess is that simplicity wins in this situation.  Apache users get a 
response that they can probably interpret, other people get a response 
that is meaningless, and therefore won't lead them on a wild goose chase.

Joshua.

Re: Bye bye welcome page

[Joshua Slive]

On Tue, 5 Oct 2004, Graham Leggett wrote:
Joshua Slive wrote:
No, because this is a very confusing and ambiguous statement from the 
perspective of a random web surfer who stumbles on the page.  Their 
response is "Why are you saying I installed a webserver on my computer? 
This must be some kind of security breach.  Call in the marines!"  (And I'm 
hardly exagerating!)
Point... How about "The website you have accessed has not yet been 
configured. Please try to access this website again later."? It's directed at 
end users, and does not imply anywhere that the server might be running on 
their local machine.
My opinion is that the shorter message is better because, by the fact that 
it gives no information at all, it is less likely to be misinterpreted to 
mean something that the website owner doesn't intend.

I won't object if someone wants to put another piece of text there, as 
long as it doesn't start us back on the same road we left 5+ years ago 
with this page.

Joshua.

Assigning bugs in bugzilla

[Joshua Slive]

It is probably not a good idea to use the Assigned-to field in our 
bugzilla install for taking ownership of issues.  If you do this, then 
changes to the bug will no longer go to our bugzilla mailing list, which 
could create gaps in oversight.

I suggest (in decreasing order of preference):
- Add yourself to the cc: list, and add a note saying that you are looking 
into the bug; or

- Change the Assigned-To field, but add [EMAIL PROTECTED] to the cc: 
list.

Joshua.

Re: cvs commit: apache-1.3/src/modules/standard mod_include.c

[Joshua Slive]

On Fri, 22 Oct 2004 [EMAIL PROTECTED] wrote:
 +   1.3.32: Tagged October 18, 2004. Not released.
It may be silly to argue over, but for all intents and purposes, 1.3.32 
was released.  We just never sent an email announcement.  It's on the 
website, it's in the distribution directory, and it hit slashdot.

Formally, I think we can consider something released once it hits 
/dist/httpd/.

Joshua.

Re: mod_actions 1.32 patch never made it to 2.0

[Joshua Slive]

André Malo wrote:
* Cliff Woolley wrote:

So why is this same general behavior unconditional in httpd 1.3 but
non-existant in 2.0 and requires a "virtual" flag on 2.1?  Andre?
Thoughts?  The "virtual" thing was your doing...

see STATUS file. It's already voted for backport, just didn't make it yet...
The reason for the virtual flag is that it should be a user decision whether 
the httpd should generate the 404 (with errordocument and all) or not. IMHO 
the unconditional behaviour in 1.3 was a mistake (made in version 1.3.10). 
2.x was forked in 1.3.9 :-)
I agree.  Action was designed to enable processing files via CGI 
scripts, not to handle arbitrary URLs.

Ryan's example (and most others that want this behavior) would be more 
cleanly handled with a simple

ScriptAlias /foo /full/path/to/cgi-bin/printenv
Joshua.

svn commit: r360207 - in /httpd/httpd/branches/authz-dev: include/http_core.h server/core.c

[Joshua Slive]

[Looks like this didn't go through the first time.  Do we still have
active moderation on this list?]

-- Forwarded message --
From: Joshua Slive <[EMAIL PROTECTED]>
Date: Jan 1, 2006 5:28 PM
Subject: Re: svn commit: r360207 - in /httpd/httpd/branches/authz-dev:
include/http_core.h server/core.c
To: dev@httpd.apache.org


On 12/30/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: bnicholes
> Date: Fri Dec 30 16:28:46 2005
> New Revision: 360207
>
> URL: http://svn.apache.org/viewcvs?rev=360207&view=rev
> Log:
> Remove the 'satisfy' directive and the ap_satisfy() and ap_requires() APIs 
> since they no longer serve a purpose

You probably already have thought of this, but I'll point out the
obvious anyway.

These changes are much more invasive in terms of upgrade-path than
anything in the 1.3 to 2.0 change.  In particular, they will break
almost all .htaccess files, which the earlier changes did not.  This
will make it almost impossible for many people to upgrade.

Has there been any thought to keeping the old directives in a
compatibility module or something like that?

Joshua.

Re: Merging branch authz-dev - Authorization and Access Control 2.3 vs. 2.2

[Joshua Slive]

On 1/6/06, Brad Nicholes <[EMAIL PROTECTED]> wrote:
>The Authz refactoring in /branch/authz-dev is basically done and I am
> about ready to  merge the branch back into trunk.  Before I do that, I
> would like to describe the impact  that the Authz change will have going
> forward, as well as the benefits.  All of this  looks like a massive
> change to authorization and access control, which granted it is.
> However, I have tried as much as possible to minimize the impact to
> existing  configuration files.

These are my comments based on a very superficial look.

First, I think the overall idea is great and much clearer than what we have now.

But I do think the necessary config changes are rather massive,
touching a large percentage of .htaccess files and 
sections, not to mention third-party auth modules.  I would think
that, by sacrificing some purity, it should be possible to support
many of these configs and modules.  For example, shouldn't it be
possible to create a mod_access_deprecated that impliments
Order/Allow/Deny?  Obviously satisfy would add a lot of complication,
but I bet 90%+ of existing configs would work fine if the default
Satisfy All was made to work, so the Satisfy directive itself probably
wouldn't need to be included.

I guess an alternative would be a fancy python script to convert
config/.htaccess files.

As far as the new config directives, a couple questions:

1. Why split "Allow from" into "Require ip" and "Require host".  There
is no ambiguity between a hostname and an IP address, as far as I
know, so it would seem more straightforward to have only "Require
host" and let httpd figure out whether it is an IP address or
hostname.

2. "Require all granted" and "Require all denied" seem a little obtuse
to me.  As evidence, I note that you chose to document them by
refering to the old config, rather than explaining what they do ;-) 
Perhaps simply "Require host *" and "Reject host *" or "Require host
all"/"Reject host all" would be clearer alternatives.  (In the
process, getting rid of another Require option and getting us closer
to a more familiar config.)

3. The  and  names seem a touch confusing
given that they apply to both require and reject directives.  Perhaps
back to the good old  or ?

4. It isn't made clear anywhere whether RequireAll or RequireOne is the default.

Joshua.

Re: Merging branch authz-dev - Authorization and Access Control 2.3 vs. 2.2

[Joshua Slive]

[Your merge today prompted me to dig out a response I started but
never finished.]

I am still worried that we are underestimating the pain that this will
cause.  In my opinion, a config change that requires substantial
changes to every httpd.conf and many .htaccess files requires a major
version bump (to 3.0) unless it can, in some way, be made seamless to
the end user.  And there is no way to deny that this will put a large
roadblock in the way of upgraders.

On 1/6/06, Brad Nicholes <[EMAIL PROTECTED]> wrote:
>I believe that this could probably be done.  Basically "Allow from"
> was split into the 'IP', 'Host', etc. providers because that is how it
> was represented in the source code and it just naturally fell out that
> way.

From a code perspective, I understand.  But the directives should be
structured from a user perspective as much as possible.  I'd prefer to
see just the "host".

>   Honestly, I struggled with this naming myself but really couldn't
> come up with anything better that would accurately represent "Allow from
> all" or "Deny from all" and still fit the authz provider model.  I'm not
> sure that  "Require host all"/"Reject host all" quite fits it either
> because we aren't always talking about a host.

But using host maps very well to how people currently think about
this.  Host is the base access control method and other things are
generally built on top.  Again, I'd prefer to see this folded back
into host.

> > 4. It isn't made clear anywhere whether RequireAll or RequireOne is
> the
> > default.
>
>   Yeah it probably needs to be stated somewhere,  however the default
> is  basically because that is how it works today if you use
> multiple Require directives.  I guess I kind of expected that to be
> obvious.

Well, very few people use multiple require directives, so I don't
think it is so obvious.  And the default to the old Satisfy directive
is All, which is equivalent to .  Obviously there is no
way to keep both of these old behaviors, so it winds up being a major
change either way.

Joshua.

Re: Merging branch authz-dev - Authorization and Access Control 2.3vs. 2.2

[Joshua Slive]

On 1/12/06, Brad Nicholes <[EMAIL PROTECTED]> wrote:
>   OK, try this on for size.  Since Order,Allow,Deny are all hooked at
> the access_checker stage, we should be able to add these directives back
> in and allow them to function normally.  The real problem is 'Satisfy'
> because it had its fingers into the middle of
> ap_process_request_internal().  So to get around this problem, I added
> the directive back into mod_authz_host (along with Order,Allow,Deny) and
> let it do it thing also.  'Satisfy All' is the default (as it was
> before) meaning that if the access_checker fails or the authz_checker
> fails, then the entire request fails.  But if 'Satisfy Any' is specified
> then if the access_checker fails, it makes a note of that fact in the
> request_rec->notes and defers to the authz_checker.  If the
> authz_checker fails, obviously the request fails.  But if the request
> makes it all the way to the mod_authz_default handler, this handler
> checks the note and determines whether or not to authorize or reject the
> request based on what the current state of both access control and
> authz.
>
>So what this means is that Order,Allow,Deny,Satisfy are back and
> *should* function as before along side of the new authz model.  This
> should resolve the backward compatibility issue with the following
> caveat.  Both mod_authn_default and mod_authz_default modules must be
> loaded.  These module implement the catch-all handlers that allow things
> to work if no authn or authz is implemented for a  or
> .  Otherwise access is automatically denied. What I would like
> to see is the above  *should* confirmed to be a *do*.  In other words, I
> am looking for some help testing this.  Any takers?  So far my testing
> shows that things are good.

The idea seems right to me.  I'll try to find time to do some testing,
but I'm pretty backed-up at the moment.

I would consider moving this compat code into mod_access_compat or
something of the like so that it would be easy for people to select
whether they want the clean new system or a mix of the new and old
system.  Since this change will not come until at least 2.4, I think
it is acceptable to have module name changes (as we did from 2.0 to
2.2).

Joshua.

Re: Improving documentation / configuration as a result of report 38123

[Joshua Slive]

On 1/17/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>
> A short time ago there had been a discussion on the security list(s)
> if bug report 38123 (Apache stops receiving new connections) is a new
> and unknown vulnerability or not.

If you want to attract lazy people to the topic, you should provide a link ;-)
http://issues.apache.org/bugzilla/show_bug.cgi?id=38123

>
> 1. I think the comment
>
>"It is not set any lower by default because there may still be odd places
> in the code where the timer is not reset when a packet is sent."
>
>on http://httpd.apache.org/docs/2.0/en/mod/core.html#timeout
>
>is not valid for 2.0.x and up. AFAIK the Timeout was implemented in 1.3
>with the help of the alarm function which justifies this remark, but this
>is no longer true since 2.0 where poll is used.

+1  I think we'd at least prefer that if any of these edge cases still
exist in the code, they be treated as bugs and not expected behavior.

>
> 2. There should be a section on the Security Tips page that mentions this
>issue and makes some remarks on it.

+1  Although you'll note that the security tips page is really just a
big mess.  It needs someone with some real-world knowledge to point
out what is important.

> 3. From my point of view, the default value of 300 seconds for Timeout seems 
> to
>be far too high for most purposes. I would suggest to lower this at least
>to 10 seconds. Of course this can lead to trouble at least with long 
> running
>cgi scripts.

That sounds like a little too drastic a change to me without testing
to back it up.  Pehaps 60 would be a good intermediate step.  One
problem is that TimeOut applies to to many different things.  Why
should the timeout waiting for CGI output and the timeout waiting for
the network be the same?  It would be nice to have more fine-grained
control.

(And it would also be nice to unify all the different timeouts used by
the server in some way; ie, "TimeOut cgi=60 request=5 ldap=10 dav=50",
etc.  But perhaps that is asking for too much.)

Joshua.

Re: Improving documentation / configuration as a result of report 38123

[Joshua Slive]

On 1/17/06, Joshua Slive <[EMAIL PROTECTED]> wrote:

> > 2. There should be a section on the Security Tips page that mentions this
> >issue and makes some remarks on it.

Since we really need a place to point everyone who rediscovers this
issue and thinks they've found something original, I started a draft,
which you can see here:
http://httpd.apache.org/docs/trunk/misc/security_tips.html#dos

It obviously could use some work.

Joshua.

Re: svn commit: r369827 - /httpd/httpd/trunk/docs/manual/misc/security_tips.xml

[Joshua Slive]

On 1/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: rpluem
> Date: Tue Jan 17 08:08:28 2006
> New Revision: 369827
>
> URL: http://svn.apache.org/viewcvs?rev=369827&view=rev
> Log:
> * Add some remarks how to mitigate the risk of DoS attacks by setting
>   proper values for the Timeout and Keepalive parameters.

Hmmm... Looks like we collided here.  You should have got an
out-of-date message from subversion when you tried this commit...

Joshua.

Re: Thread-only execution with Apache 2 : Newbie query

[Joshua Slive]

On 1/19/06, Praveen Bhaniramka <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> We are developing a custom module for Apache using mod_gsoap over Linux.
> However, our software currently does not work very well in a
> multi-process environment as it was designed primarily for a
> multi-threaded environment.
>
> Is there a way to configure Apache such that it uses threads only
> instead of using processes for handling HTTP requests? I looked at the
> Apache documentation and it seems that the default MPM modules, prefork
> and worker, use processes by default. The worker module seems to allow
> both models of execution. Is it possible to configure it to use threads
> only?
>
> Thanks for any useful pointers.

Yes, worker should be able to do this, although it will not adjust to
load (you need to prespecify exactly how many threads will be
available at all times).  Something like:
ServerLimit 1
StartServer 1
MaxClients 512
ThreadsPerChild 512
MaxSpareThreads 512
MinSpareThreads 0

Joshua.

Re: Thread-only execution with Apache 2 : Newbie query

[Joshua Slive]

On 1/19/06, Praveen Bhaniramka <[EMAIL PROTECTED]> wrote:
> Hi Joshua,
>
> Thanks for your reply. I tried setting the parameters suggested by you.
> But when I re-run httpd2, I see that it is still creating 3 processes.

Three processes is normal.  One is the control process, one is the cgi
daemon and one is the main server process.  Only the latter should be
serving requests.

Joshua.

Re: Dynamic configuration

[Joshua Slive]

On 1/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> There should be feature to dynamically update configuration ( module
> configurations ) at runtime and no connection should break. I am looking at
> apache code and could not get any clue. Can anyone suggest me where to start
> for this?

apachectl -k graceful

Re: Change in how to configure authorization

[Joshua Slive]

I haven't done any of this work myself, but...

On 1/26/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> Hi.
>
> It looks like recently some people have changed how authorization is
> working on the trunk.
>
> Could those people please
>
> 1. add a note to docs/upgrading.html to document what us idiots need to
> do to get our config to work again?

This will need to be done eventually, but I think it can wait until
things settle out a litt.e

>
> 2. change httpd-std.conf so it doesn't reference the depcreated stuff

I believe this was done.  What errors are you getting?  Are you sure
you are using the most recent httpd-std.conf.in from trunk?

>
> 3. fix core.html.en so it has the 'satisfy' directive (my version doesn't)

Satisfy is now deprecated and contained in mod_access_compat.

Joshua.

Re: Change in how to configure authorization

[Joshua Slive]

On 1/26/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> Hi Joshua:
>
> httpd.conf.in has the new structure
> httpd-std.conf (the one I was looking at) didn't ;(

Hmmm... httpd-std.conf doesn't exist in trunk.

Joshua.

Re: svn commit: r375083 - in /httpd/httpd/trunk/docs/manual/faq: background.html.en background.xml

[Joshua Slive]

On 2/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: niq
> Date: Sun Feb  5 11:30:29 2006
> New Revision: 375083
>
> URL: http://svn.apache.org/viewcvs?rev=375083&view=rev
> Log:
> PR#38521 - fix link.

> -You may use the  href="http://httpd.apache.org/docs/apache_pb.gif";>'Powered by Apache'
> +You may use the 'Powered by Apache'

If you are pointing outside the current docset, you should use an
absolute URL to make sure it works for people who install the docs
locally.

joshua.

mod_mbox cores on ajax

[Joshua Slive]

I hadn't checked in a while, but there seem to be lots of mod_mbox
cores on ajax again.  Here's one backtrace:

#0  mbox_cte_escape_html (p=0x60343ca8,
s=0x602f5a68
"--_=_NextPart_001_01C3C08D.F854E1E0\nContent-Type:
text/html;Content-Transfer-Encoding: quoted-printable\n\n

Re: Change in how to configure authorization

[Joshua Slive]

On 2/10/06, David Reid <[EMAIL PROTECTED]> wrote:
> Joshua Slive wrote:
> > On 1/26/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> >
> >>Hi Joshua:
> >>
> >>httpd.conf.in has the new structure
> >>httpd-std.conf (the one I was looking at) didn't ;(
> >
> >
> > Hmmm... httpd-std.conf doesn't exist in trunk.
>
> Just ran into this and couldn't quite believe what I was seeing.
>
> I have a similar config on a server and basically unless you're very
> careful you end up shutting people out! This change in auth seems to
> make no sense to me.
>
> It's adding a lot of complexity to config files. Do we really need to
> make this change? Really?
>
> At the very least can someone please document how config files need to
> be changed... And no, I don't think having it in a sample config file is
> enough.

No argument on any of that.  But the idea is that if you include
mod_access_compat, it should be config-file-compatible with older
versions.
If that isn't true, you should provide details.


Joshua.

Re: how does this get changed?

[Joshua Slive]

On 2/16/06, David Reid <[EMAIL PROTECTED]> wrote:
> Rather than try and piece it together, can someone simply answer this
> simple question? Maybe then this mail and your reply will help other
> poor souls trying to make the change.
>
> Convert this
>
> Order deny,allow
> Deny from all

Require all denied

But David, you should really just be including mod_access_compat.  I
think there are plenty of people here who are going to vote against
any release of 2.4 unless configurations like the one above work out
of the box with mod_access_compat included.  So if you are having
problems, it is better to identify them now.

Joshua.

Re: how does this get changed?

[Joshua Slive]

On 2/16/06, Graham Leggett <[EMAIL PROTECTED]> wrote:
> Ian Holsman wrote:
>
> > maybe if mod_access_compat is included by default statically into httpd
> > itself? (unless explicitly disabled)
> >
> > we could make it optional in 2.6 (and remove docs on it), and remove in
> > 2.8 or something. this will give people plenty of time to switch over.
>
> This definitely makes sense, +1.

Uhh... Please don't remove docs on something that is still in the
server.  And it should be removed at 3.0.  We shouldn't be breaking
config files in minor releases.

Joshua.

Re: how does this get changed?

[Joshua Slive]

On 2/16/06, Joost de Heer <[EMAIL PROTECTED]> wrote:
> > Uhh... Please don't remove docs on something that is still in the
> > server.  And it should be removed at 3.0.  We shouldn't be breaking
> > config files in minor releases.
>
> Already happened between 2.0 and 2.2, when mod_access was changed to
> mod_authz_host.

That is a change to ./configure command line options and possibly
LoadModule directives, but not really a direct change in the config
file syntax.

Joshua.

Re: how does this get changed?

[Joshua Slive]

On 2/17/06, Joost de Heer <[EMAIL PROTECTED]> wrote:

> 'Breaking a config file' is IMO that you can't just copy your 2.0 config file
> and it works. And the new mod_auth(n|z) structure just did that: A 2.0 config
> file needed changes to work in 2.2.

Only if you are using dynamically loaded modules.  It works fine
except for LoadModule lines.

Joshua.

Re: Integration Apache2.0.48 and an existing server

[Joshua Slive]

On 2/25/06, Arshad Ahamad <[EMAIL PROTECTED]> wrote:
> Hello all,
>
>
> I have configure Apache-2.0.48 successfully.Now I would like to
> integrate Apache-2.0.48 and existing server. So I am unable to start this
> work ,I am too much confused either Apache embedded into the existing server
> OR existing serve embedded into the Apache Or other way But in these cases
> this is realy a difficult work.
>
> so any one can suggest me what I do for that, whith some hint.

You need to much better define what you mean by "existing server".

And it is really silly to be starting a new project with 2.0.48.  That
version is way out of date.

Joshua.

Re: Protecting a file with a password

[Joshua Slive]

On 3/6/06, Graham Leggett <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I have just tried to convince httpd v2.2.0 to password protect a single
> file on the filesystem, but without any success.
>
> Does anybody know whether this is possible?
>
> I tried
>
> 
>
> and
>
> 

The first one should work.  The last one won't.  The recommended
config is something like


...



We should really give an error if you try to use a slash in a  statement.

Joshua.

Re: HTTP_X_FORWARDED_FOR in mod_proxy

[Joshua Slive]

On 4/18/06, Matthias Behrens <[EMAIL PROTECTED]> wrote:
> hi
>
> is there a way to overwrite the HTTP_X_FORWARDED_FOR instead of adding to
> it?
>
> the problem is that the content of this headerline is sometimes totally
> chaotic so its very difficult to parse.
> other possible solutions would be:
>
> - to clear the HTTP_X_FORWARDED_FOR before processing the request. (dont
> know how to do) or
>
> - using a different header / env.variable to protokoll the original
> ipaddress (dont know how to do it eather)

The RequestHeader directive, with or without the "early" option, may
be able to clear the old X-Forwarded-For header.  Otherwise, you'll
need to edit the mod_proxy_http source to change the name of the
header.

Joshua.

Re: HTTP_X_FORWARDED_FOR in mod_proxy

[Joshua Slive]

On 4/20/06, Matthias Behrens <[EMAIL PROTECTED]> wrote:
> thx
>
> doesnt seem to work on 2.0
>
> its a 2.2 feature isnt it?
>

The "early" option, which may be necessary here, is a 2.2 feature.

Joshua.

Re: copyright notices

[Joshua Slive]

On 4/21/06, Roy T. Fielding <[EMAIL PROTECTED]> wrote:

> I don't know of any reason to hurry a 2.0.x release (heck, I don't
> know of any reason to continue its development), but I also don't think
> releasing one with modified copyright years is any more or less legal
> than continuing to distribute the previous releases.  Nor do I think
> any of our users will ever care enough to challenge the notices.

+1

Re: 304 response handling with Apache 2.0.53

[Joshua Slive]

On 4/24/06, Swapan Gupta <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I am using Apache 2.0.53. I am observing that when a 304 "Not Modified"
> response is returned accompanied by the "Location" header, the
> "Location" does not reach the user.
>
> I could see that this header is not mentioned in the RFC for 304
> response. However, IIS does send this header back to the user along with
> the 304.
>
> So, I wanted to check if Apache does some special handling restricting
> this Response header to be passed back to the user?
>
> Is this a problem with Apache 2.0.53? If yes, has it been addressed in
> any of the future Apache versions?
>
> Looking forward to your response.

I'm not sure what you are trying to do, but RFC 2616 Section 10.3.5 is
pretty clear that only certain headers should be sent in a 304, and
Location isn't one of them.

Joshua.

Fwd: Email address on mail archive (fwd)

[Joshua Slive]

This type of request is becoming more and more common.

Although mod_mbox obscures the basic to and from address, there are
still two problems:

1. It doesn't obscure email addresses in the body of the message
(which could be from forwarded/quoted messages).

2. The "raw" link still gives access to the unobscured addresses.

I know there are people who still hold the idealistic view that we
shouldn't be obscuring email addresses at all.  Although I agree in
principle, I think the world has passed that view by.

I don't know if anyone is interested in fixing this stuff, but I
thought I would at least point out the recurring issue to the mod_mbox
developers.

Joshua.

-- Forwarded message --
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Apr 27, 2006 7:49 AM
Subject: Email address on mail archive (fwd)
To: [EMAIL PROTECTED]



Sorry -- I can't recall -- what's the policy on this kind of
request?

--j.

--- Forwarded Message

Date:Tue, 25 Apr 2006 08:21:17 +0100
From:Jens Finke 
To:  [EMAIL PROTECTED]
Subject: Email address on mail archive

Hi,

I posted a bug report to spamassassin.dev in November 2004. Rather ironically,
I notice that my email address has been visible on the mail-archives.apache.org
 website ever since. Much as I appreciate Spam Assassin, having my primary addr
ess accessible to any web trawling spambot rather defeats the whole point.

So, could you please delete the address (jens bluegecko.org) from the following
 four pages:


http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200411.mbox/%3C200411
[EMAIL PROTECTED]

http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200411.mbox/raw/%3c20
[EMAIL PROTECTED]

http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200411.mbox/%3C200411
[EMAIL PROTECTED]

http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200411.mbox/raw/%3c20
[EMAIL PROTECTED]

Many thanks,

Jens Finke
--
http://www.bluegecko.org
-  Traditional Music and Cultures of Kenya
-  Chasing the Lizard's Tail: across the Sahara by bicycle

Mjinga akierevuka mwerevu yupo mashakani
When a fool becomes enlightened, the wise man is in trouble




--- End of Forwarded Message

Re: Email address on mail archive (fwd)

[Joshua Slive]

On 4/28/06, Justin Erenkrantz <[EMAIL PROTECTED]> wrote:

On 4/27/06, Joshua Slive <[EMAIL PROTECTED]> wrote:
> I know there are people who still hold the idealistic view that we
> shouldn't be obscuring email addresses at all.  Although I agree in
> principle, I think the world has passed that view by.

I think that obfuscation is completely pointless.  You're posting to a
*public* mailing list.  If you can't understand that, well, I just
don't care about people who whine.  The *only* solution that is valid
is to use anti-spam tools on your end.  I have no desire to get into a
never-ending arms race with spammers.  We can't win that battle on
those terms.  -- justin


As I said, I'd love to agree with you.  But why don't you try asking
100 random subscribers to our users lists or 100 random bug submitters
whether they think it is obvious that their email address will be made
public.  A couple years ago, they might have agreed.  Now, I'd guess
the majority wouldn't think that is obvious at all.

Joshua.

Re: apr_brigade_insert_file() LFS/Linux issues

[Joshua Slive]

On 5/3/06, Joe Orton <[EMAIL PROTECTED]> wrote:

On Wed, May 03, 2006 at 02:39:33PM +0200, Niklas Edmundsson wrote:
> I've run into apr_brigade_insert_file() creating brigades that's not
> possible to sendfile() (EINVAL), this is with httpd-2.2.2 on Ubuntu
> Breezy Linux amd64 (64bit). The file in question is 4.3GB, and it
> seems that sendfile() doesn't cope with that.
>
> Has anyone else seen this?

No, works fine here.  Can you get strace output for the failing call?


Just a random note: There was a report of a problem with 2.2.2 and
mod_include on the users list that went away when sendfile was turned
off.  Sounds similar.

Joshua.

Re: Laying undead myths to rest

[Joshua Slive]

On 5/8/06, Nick Kew <[EMAIL PROTECTED]> wrote:

There are a few undead "apache myths" still floating around,
due to clueless third-party tutorials.  I wonder if there's any value
in countering these zombies with specific notes in our documentation.

Here's an example patch of the kind I have in mind:


There isn't much hope to fight this sort of thing when it is still the
only recommended configuration in the php docs:
http://www.php.net/manual/en/install.unix.apache2.php

If you still want to add a note, I suggest something more along the lines of

Magic MIME types
In very early versions of the Apache HTTP Server, the
AddType directive was also used to activate
special server-side processing (such as mod_include
or PHP) by assigning "magic" MIME types to files.  This  can create
problems in more recent versions and should be avoided in favor of
using the AddHandler directive.

Joshua.