Re: mod_rewrite: different behaviour on sub-requests - Why?

[Cliff Woolley]

On Wed, 6 Aug 2003, André Malo wrote:

> Hmm. After further thinking about it... I'm in favour of removing the
> check in 2.1. But I wouldn't backport it, since it *may* lead to a
> different behaviour of existing rules.

I'm leaning on leaving it as-is for that same reason unless there's a
clear reason to change it...

--Cliff

Re: Darwin and IPv6 was Re: cvs commit: httpd-2.0/server listen.c

[Justin Erenkrantz]

--On Thursday, August 14, 2003 23:43:23 +0100 "Colm MacCarthaigh,,," 
<[EMAIL PROTECTED]> wrote:

good good, patch works so :) In which I'll now cc [EMAIL PROTECTED] and include
the neccessary autoconf voodoo to fix OSX/Darwin.
I'm not entirely sure the getnameinfo() patch is needed on current releases 
of Darwin.  Host-based authorization *seems* to work without it.

Can someone please verify this to make sure I'm not doing something wrong 
or misunderstanding what the original problem was 10 months ago or whatnot?

It's very possible this was fixed in a point release since last October. 
If so, we can allow IPv6 on 10.2.6 and perhaps earlier versions if we can 
get confirmation on those versions.  And, we *could* also enable it on 
known-getnameinfo()-broken releases with this patch in place.  But, I'm not 
really tempted to go that far.  -- justin

Re: mod_rewrite: different behaviour on sub-requests - Why?

[André Malo]

* Ralf S. Engelschall wrote:

>>> (see bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21814 ).
>>>
>>> I suggest to disarm this section if not removing it from mod_rewrite.c...
>>
>> This was added immediately after the inclusion of mod_rewrite into
>> the httpd code (some years ago). I believe, the only one who can say,
>> _why_ this was added, is Ralf :). However, I'll take a look into it.
>> This was probably added in order to avoid mod_rewrite-loops. Perhaps
>> it isn't necessary any longer.
> 
> No, sorry, I cannot remember myself. But you can be right, it looks like
> it was to prevent loops. The only other possible reason I can think of
> is that it was to perhaps speed up processing. But, as I said, I no
> longer can remember the real reason.

Hmm. After further thinking about it... I'm in favour of removing the check in
2.1. But I wouldn't backport it, since it *may* lead to a different behaviour
of existing rules.

Any Opinions?

nd

Re: File buckets v. core_output_filter

[Cliff Woolley]

On Thu, 7 Aug 2003, Bojan Smojver wrote:

> > So, I build up a brigade that looks like this:
> >
> > FILE - POOL - FILE - POOL - FILE - EOS
> >
> > When I pass this to output filters in my handler with
> > ap_pass_brigade(r->output_filters,bb), I'm getting completely random
> > output from. In other words, offsets of FILE buckets are completely
> > screwed or buckets down show up at all.

Somehow I'm unsurprised that that particular sequence causes a problem.
There is (or at least used to be) a special codepath for sendfiling
multiple file buckets in the core_output_filter.  It doesn't get hit all
that often, I'd imagine.

I'll try to construct a test for that case and see what's going on in core
output.  Hey Greg... seen anything like this?

--Cliff

Re: File buckets v. core_output_filter

[Bill Stoddard]

Cliff Woolley wrote:
On Thu, 7 Aug 2003, Bojan Smojver wrote:


So, I build up a brigade that looks like this:

FILE - POOL - FILE - POOL - FILE - EOS

When I pass this to output filters in my handler with
ap_pass_brigade(r->output_filters,bb), I'm getting completely random
output from. In other words, offsets of FILE buckets are completely
screwed or buckets down show up at all.


Somehow I'm unsurprised that that particular sequence causes a problem.
There is (or at least used to be) a special codepath for sendfiling
multiple file buckets in the core_output_filter.  It doesn't get hit all
that often, I'd imagine.
I'll try to construct a test for that case and see what's going on in core
output.  Hey Greg... seen anything like this?
--Cliff

I've not looked in core_output_filter for a while but I know in the past 
 the intent was to not use sf at all if more than one fd bucket was in 
the brigade. Maybe that's broken or intentionally changed...

Bill

ap_run_sub_req problem

[Aryeh Katz]

In certain circumstances, I need to do an internal redirect on the client's 
request (without sending back a redirect to the client).
I tried using ap_sub_req_method_uri (specifying NULL for the filter), and then 
ap_run_sub_req.
I see that the content type of the new request is correct (in my case, 
image/gif). However, when the request is sent to the client, the content type 
is text/plain. Thus, the reply to the client doesn't render properly.
I suspect I am not invoking ap_run_sub_req properly.
Is there something I should know about how to invoke run_sub_req?
Thanks.
Aryeh

---
Aryeh Katz
Secured-Services Inc.

does perchild work in Linux?

[Jeremy Hansen]

I've been trying to use perchild and I've been looking for information on 
whether this is actually work or not.  I realize this is an experimental 
module but I'm just trying to eliminate the possibility that it's a 
configuration problem vs. a broken module.

As soon as I assign more then one ChildPerUserID and coresponding virtual 
host, apache just hangs and will no longer serve our pages.

I see the processes for each ChildPerUserID in ps.

If someone says, yes, this is broken, swell, but I'm just trying to be 
sure I'm not just doing something wrong in my config. 

Here is my config for perchild:

AcceptMutex  fcntl
LockFile logs/accept.lock
ServerLimit  100
NumServers   20
StartThreads 10
MinSpareThreads  10
MaxSpareThreads 20
MaxThreadsPerChild  40
MaxRequestsPerChild  0

ChildPerUserID virtual virtual 2
ChildPerUserID methsea methsea 2
ChildPerUserID ssltest ssltest 2

and here is an example of one of my virtual hosts:


# SuexecUserGroup methsea methsea
AssignUserID methsea methsea
ServerAdmin [EMAIL PROTECTED]
DocumentRoot /home/WWW/methanesea.com/htdocs
ServerName methanesea.com
ServerAlias www.methanesea.com
ErrorLog /var/log/httpd/methanesea.com/error_log
CustomLog /var/log/httpd/methanesea.com/access_log combined
ScriptAlias /cgi-bin/ /home/WWW/methanesea.com/cgi-bin/


Thanks for any feed back.

-jeremy

Re: File buckets v. core_output_filter

[Bojan Smojver]

Just wanted to ask if you guys need me to open up a bug in Bugzilla for
this?

Also, I did a bit more testing on the whole thing and my example from
the initial report, where I had 300 byte long file buckets, doesn't
actually produce problems - I just picked that number because I believed
that on AP_MIN_SENDFILE the _only_thing_ that was involved. In the real
module that I'm building, my file buckets were over 6 kB long mixed with
some of them that are a few tens of bytes long. So, it seems that the
buckets have to be a few kB long to affect the output adversely. Not
sure if that's related in some way to how the actual TCP packets are
handled or not, given they get cut off around 1500 mark on ethernet. I
also discovered that when longer and shorter buckets get mixed together,
that's when things get really funky.

What I was actually experimenting with was setting the AP_MIN_SENDFILE
to just under 6 kB and just over 6 kB and this was definitely triggering
the odd behaviour as long as sendfile functionality was used (i.e. the
buckets were over the limit). I even tried to disable OS sendfile
support, but that didn't seem to make any difference, so I'm inclined to
believe it is not an inherent OS problem (Red Hat Linux 9). It would be
interesting to see what other Unix flavours and Windows do with it.

Anyway, the mod_testfilebucket + the actual example file should be a
good enough starting point for testing in relation to this (the example
file is supposed to have Unix line endings, LF only - on Windows this
file might have an incorrect size). You might want to experiment with
different file bucket sizes, just to make sure that all the above
analysis isn't some kind of a fluke.

The reason I didn't attach the actual module that I'm building is
because it involves other things apart from pure bucket handling, like
scanning, using reentrant C Flex, which not all people have at this
point. But if that helps, it's not an issue - it is a GPL-ed piece of
software.

I have tried to follow the logic of the core_output_filter a bit, but I
have to say it would take me some time to figure the whole thing out -
it's not really obvious to me what happens.

-- 
Bojan

Re: ap_run_sub_req problem

[Aryeh Katz]

Bill,
I was wondering if the following in the filter documentation is a doc bug based 
on your comments below:

"The second case for sub-requests is when one sub-request is going to 
become the real request. This happens whenever a sub-request is created 
outside of a handler or filter, and NULL is passed as the next filter to the 
make_sub_request function."

This seems to imply that it is possible to pass a NULL for the filter, and still 
have it become the real request (which I assume is done in a method similar 
to run_sub_req).
Can you shed some light on this please?
Thanks.
Aryeh


> The NULL argument for the filter is *ONLY* to be used for testing
> subrequests that are not actually run to the client.  E.g.
> mod_autoindex uses the NULL arg to consider what files might be
> served, and if they are, in fact, actually valid content files, or if
> they have been protected or otherwise cannot be handled.
> 
> You must pass the appropriate filter arg in order to pass the response
> through the filter stack back to the client.
> 
> Look, instead, at mod_include.c or another module that actually serves
> the subrequest, for an example of the appropriate way to use this API.
> 
> Bill
> 
> At 02:37 PM 8/6/2003, Aryeh Katz wrote:
> >In certain circumstances, I need to do an internal redirect on the
> >client's request (without sending back a redirect to the client). I
> >tried using ap_sub_req_method_uri (specifying NULL for the filter),
> >and then ap_run_sub_req. I see that the content type of the new
> >request is correct (in my case, image/gif). However, when the request
> >is sent to the client, the content type is text/plain. Thus, the
> >reply to the client doesn't render properly. I suspect I am not
> >invoking ap_run_sub_req properly. Is there something I should know
> >about how to invoke run_sub_req? Thanks. Aryeh
> >
> >---
> >Aryeh Katz
> >Secured-Services Inc.
> 


---
Aryeh Katz
Secured-Services Inc.

Re: cvs commit: httpd-2.0/modules/ssl ssl_engine_kernel.c

[Greg Stein]

On Thu, Aug 07, 2003 at 11:57:12PM -, [EMAIL PROTECTED] wrote:
>...
>   +++ ssl_engine_kernel.c 7 Aug 2003 23:57:11 -   1.98
>   @@ -880,6 +880,8 @@
>password = auth_line;
>
>if ((username[0] == '/') && strEQ(password, "password")) {
>   +ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
>   + "Encountered FakeBasicAuth spoof: %s", username);
>return HTTP_FORBIDDEN;
>}

Hmm. You have a request_rec there. How about:

   ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
 "Encountered FakeBasicAuth spoof: %s", username);

Providing the request means that you get more information in the error_log.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Problem designing modul

[Bert Radke]

Hi list,

I have received the task to write a modul to solve a particular problem in
one of our applications. We use the Oracle IAS with Apache 1.3 and
mod_plsqll. Some of the requests involve long-running DB queries. 
Unfortunatily
this long queries cause one proxy to think that that there is a problem ..

So the idea is to have a modul, that relays the request to mod_plsql and
supervise that there is a resonse in a specified time. If so, the 
resulting html
is returned, otherwise the intercepting modul is to generate a page and 
waits
for mod_plsql to complete (The result of  the query is to save for later 
viewing).

I' ve done a lot of reading and managed to build a modul that generates 
some
sample code. But I have problems to understand how I can redirect the 
request to
mod_plsql and still have controll over the request. I 've read how to 
generate a
redirect or an internal redirection. But if I understand right, I would 
than not have
any way to
a) test if the request is answered in time; and
b) receive the gerated html output.

The only way I see in the monent is to open a socket and make a http 
request onto
the original destination (mod_plsql). Looking into mod_proxy, this seems 
a nontrivial
task, so I would rather avoid this.

I would be thankfull on any hints how to solve this problem, maybe there 
is a simplier
way than the one discribed?

I hope this is the right place to ask this sort of question, but I could 
not find any other.

Bert

Re: ssl/http test is failing

[William A. Rowe, Jr.]

At 02:36 PM 8/12/2003, Stas Bekman wrote:
>the ssl/http test is failing. it expect the server to send a normal 40x error 
>response with the body, however it sends 200 and HTTP/0.9. there is an impedance 
>mismatch here.

It's actually a known issue, and a matter of gracefully unplugging the ssl
decoding of the first packet.  Simplest answer may be to hang on to the
first brigade until we decide that SSL, it's not.  Then pass that entire
brigade up back to the http filter.

Bill

RE: [PATCH] mod_cache RFC compliance

[Paul J. Reder]

CASTELLE Thomas wrote:
> Hello Paul (or whoever can answer me... ;-)),
>
> I just wanted to know why the patch you committed concerning mod_cache
> hasn't been introduced in Apache 2.0.47 ? Will it be in 2.0.48 ? And
> concerning the over mod_cache RFC violations, is there any news ? I can't
> see anything on the cvs.apache.org/http2.0 website, but maybe I'm not
> looking in the right place...
> Best regards,

> Thomas.

Thomas,

Sorry for missing your note amidst the deluge awaiting my return from
vacation and thanks to Bill Stoddard for pointing this one out to me.
The lack of backport to the 2.0-stable branch was just a misunderstanding
on my part. I was looking at work to make the cache code RFC compliant
and reliable enough to move out of experimental as being development
work (thus dev-branch) rather than code-fix work (submitted for back
porting).
I committed the patch to the 2.1-dev branch back in June. I will submit
the patch for a backport vote. Once there are enough votes for it I can
backport it to the 2.0 stable branch. I can't say when it will hapen since
I have to wait for the votes to come in and I don't know if I'll get them
before 2.0.48 rolls.
Thanks for waking me up. :)

As for the other compliance issues. I am working on a patch right now
that fixes the code for looking up values in r->headers_out and
r->err_headers_out. This is the first step in resolving a number of the
compliance issues. The rest of the fixes will follow pretty close behind
and all will be submitted for backporting votes immediately.
--
Paul J. Reder
---
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein

Re: [PATCH] Default Listen with IPv6 enabled incorrect

[Colm MacCarthaigh,,,]

On Tue, Aug 12, 2003 at 09:02:52AM -0700, Justin Erenkrantz wrote:
> Nope, it's getaddrinfo('::', AF_INET6, 0) that causes the failure.  Are we 
> sure that '::' is standard?  I couldn't find any documentation to support 
> that.

It's not standard, but there isnt an implementor out there who
doesnt use it. That said using it is still a bad idea, since
there's nothing that mandates an implementor to using that
address.

RFC3493 standardises in6addr_any and IN6ADDR_ANY_INIT, which
are much better suited to the purpose. 

> >It isn't quite that simple.  If there is a non-qualified address in the
> >config, we try to figure out if the box supports IPv6, and if it does then
> >we get an IPv6 listening socket for that port.
> 
> But, if the IPv6 fails, we should go back to IPv4.  Instead, we just exit.

This is good though, if v6 is available and we can't listen there
then it should exit!

> getaddrinfo(NULL, AF_INET6, 0)
> 
> works on Solaris, but:
> 
> getaddrinfo('::', AF_INET6, 0)

This is broken, definitely. 

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/

Re: ap_run_sub_req and content length

[Justin Erenkrantz]

--On Tuesday, August 12, 2003 16:14:03 -0400 Aryeh Katz 
<[EMAIL PROTECTED]> wrote:

I wrote here earlier about using ap_run_sub_req to send a response to a
client, and I receieved excellent advice, thank you.
There is one thing I was wondering.
I see that the Encoding is chunked.
I would prefer to set the Content-Length to the correct length, rather
than use  chunked encoding.
How can I do this (other than reading the brigades, then running
ap_set_content)?
You don't really have the ability to directly control this.

The content-length filter in combination with ap_set_keepalive determine 
whether chunking is used.  Generally speaking, if the first ap_pass_brigade 
call contains the EOS, Content-Length will be sent.  Otherwise, if the 
client is HTTP/1.1, it'll use chunking.  If it is HTTP/1.0, then 
Connection: Close will be used.

Note that HTTP/1.1 mandates support for chunked-encoding.  If the client 
does not use HTTP/1.0, chunked support will not be sent.  -- justin

Re: [PATCH] Default Listen with IPv6 enabled incorrect

[Justin Erenkrantz]

--On Tuesday, August 12, 2003 3:22 PM +0100 "Colm MacCarthaigh,,," 
<[EMAIL PROTECTED]> wrote:

If IPv6 has been enabled, that should bind to :: , this is the standard
behaviour of all IPv6 apps, and to not do so would be utterly broken.
If by some quirk the OS doesn't support IPv4 over IPv6 sockets, then
getaddrinfo PF_UNSPEC magic should return the correct linked list to
handle this.
Um, then wouldn't it only be listening on IPv6 sockets, not IPv4?

Surely that can't be right.  -- justin

Re: [PATCH] Default Listen with IPv6 enabled incorrect

[Justin Erenkrantz]

--On Wednesday, August 13, 2003 1:59 AM +0100 "Colm MacCarthaigh,,," 
<[EMAIL PROTECTED]> wrote:

This is the real bug, Apache shouldn't be second-guessing getaddrinfo,
APR's call_resolver is an excellent example of how to do it properly,
AI_ADDRCONFIG is the key. Trouble is apr_sockaddr_info_get isnt
calling it for us. This is an APR bug, see the attached patch.
Okay, I just committed variants of your patch to CVS that work for me on 
Solaris.  The biggest gotcha was setting servname to be non-NULL when hostname 
was NULL.

Thanks!  -- justin

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

[Justin Erenkrantz]

--On Wednesday, August 13, 2003 16:57:34 -0600 Brad Nicholes 
<[EMAIL PROTECTED]> wrote:

in the non-getaddrinfo() implementation).  It seems that both
implementations should be sync'ed up to produce the same results.  It
appears that defaulting to "0.0.0.0" rather than NULL would be the safer
thing to do.
But, that's an IPv4 address, but we support IPv6.

Apparently, this series of commits broke Linux.  I bet this is where Joe's 
ADDRCONFIG patch comes into play.  Looking into it now.  -- justin

[STATUS] (httpd-2.0) Wed Aug 13 23:45:34 EDT 2003

[Rodent of Unusual Size]

APACHE 2.0 STATUS:  -*-text-*-
Last modified at [$Date: 2003/08/13 21:14:13 $]

Release:

2.0.48  : in development
2.0.47  : released July 09, 2003 as GA.
2.0.46  : released May 28, 2003 as GA.
2.0.45  : released April 1, 2003 as GA.
2.0.44  : released January 20, 2003 as GA.
2.0.43  : released October 3, 2002 as GA.
2.0.42  : released September 24, 2002 as GA.
2.0.41  : rolled September 16, 2002.  not released.
2.0.40  : released August 9, 2002 as GA.
2.0.39  : released June 17, 2002 as GA.
2.0.38  : rolled June 16, 2002.  not released.
2.0.37  : rolled June 11, 2002.  not released.
2.0.36  : released May 6, 2002 as GA.
2.0.35  : released April 5, 2002 as GA.
2.0.34  : tagged March 26, 2002.
2.0.33  : tagged March 6, 2002.  not released.
2.0.32  : released Feburary 16, 2002 as beta.
2.0.31  : rolled Feburary 1, 2002.  not released.
2.0.30  : tagged January 8, 2002.  not rolled.
2.0.29  : tagged November 27, 2001.  not rolled.
2.0.28  : released November 13, 2001 as beta.
2.0.27  : rolled November 6, 2001
2.0.26  : tagged October 16, 2001.  not rolled.
2.0.25  : rolled August 29, 2001
2.0.24  : rolled August 18, 2001
2.0.23  : rolled August 9, 2001
2.0.22  : rolled July 29, 2001
2.0.21  : rolled July 20, 2001
2.0.20  : rolled July 8, 2001
2.0.19  : rolled June 27, 2001
2.0.18  : rolled May 18, 2001
2.0.17  : rolled April 17, 2001
2.0.16  : rolled April 4, 2001
2.0.15  : rolled March 21, 2001
2.0.14  : rolled March 7, 2001
2.0a9   : released December 12, 2000
2.0a8   : released November 20, 2000
2.0a7   : released October 8, 2000
2.0a6   : released August 18, 2000
2.0a5   : released August 4, 2000
2.0a4   : released June 7, 2000
2.0a3   : released April 28, 2000
2.0a2   : released March 31, 2000
2.0a1   : released March 10, 2000

Please consult the following STATUS files for information
on related projects:

* srclib/apr/STATUS
* srclib/apr-util/STATUS
* docs/STATUS

Contributors looking for a mission:

* just do an egrep on "TODO", "XXX" and see what's there

RELEASE SHOWSTOPPERS:

PATCHES TO PORT FROM 2.1
  [ please place file names and revisions from HEAD here, so it is easy to
identify exactly what the proposed changes are! ]

* Correct the code in ap_check_cache_feshness to check max_age, smax_age,
  and expires correctly. This is a RFC 2616 compliance issue.
  
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/experimental/cache_util.c.diff?r1=1.26&r2=1.27
  +1: rederpj

* mod_rewrite.c: Fix mod_rewrite's support of the [P] option to send
  rewritten request using "proxy:". The code was adding multiple "proxy:"
  fields in the rewritten URI. PR: 13946.
  
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/mappers/mod_rewrite.c.diff?r1=1.153&r2=1.154
  
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/mappers/mod_rewrite.c.diff?r1=1.154&r2=1.155
  
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/mappers/mod_rewrite.c.diff?r1=1.156&r2=1.157
  
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/modules/mappers/mod_rewrite.c.diff?r1=1.173&r2=1.174
  +1: rederpj, nd

* Replace some of the mutex locking in the worker MPM with
  atomic operations for higher concurrency.
  server/mpm/worker/fdqueue.c 1.24, 1.25
  +1: brianp
  -0: trawick  These gcc warnings seem to point out uncleanness
   that should be resolved first.  Perhaps "volatile"-ity
   is inconsistent?  (gcc 3.2 on UL 1.0)
  fdqueue.c: In function `queue_info_cleanup':
  fdqueue.c:89: warning: passing arg 1 of `apr_atomic_casptr' from
incompatible pointer type
  fdqueue.c: In function `ap_queue_info_set_idle':
  fdqueue.c:142: warning: passing arg 1 of `apr_atomic_casptr' from
 incompatible pointer type
  fdqueue.c: In function `ap_queue_info_wait_for_idler':
  fdqueue.c:232: warning: passing arg 1 of `apr_atomic_casptr' from
 incompatible pointer type

* Rewrite how proxy sends its request to allow input bodies to 
  morph the request bodies.  Previously, if an input filter
  changed the request body, the original C-L would be sent which
  would be incorrect.

  Due to HTTP compliance, we must either send the body T-E: chunked
  or include a C-L for the request body.  Connection: Close is not
  an option. [jerenkrantz2002/12/08 21:37:27]
  +1: stoddard, striker, jim
  -1: brianp (we need a more robust solution than what's in 2.1 right now),
  jerenkrantz (should be fixed, but I don't have time to do this)

* Extend the SetEnvIf directive to capture subexpressions of the
  matched value. This is related to the backport proposal below ... ;

Re: Darwin and IPv6 was Re: cvs commit: httpd-2.0/server listen.c

[Justin Erenkrantz]

--On Thursday, August 14, 2003 10:20 PM +0100 "Colm MacCarthaigh,,," 
<[EMAIL PROTECTED]> wrote:

On Thu, Aug 14, 2003 at 04:56:48PM -0400, John K. Sterling wrote:
Hi Colm -

I'm not sure what to be looking for, but i applied your patch, rebuilt
(with the broken_ipv6 set to 0, of course), turned on HostnameLookups,
and my access logs have remote hostname properly resolved.
That should mean it's working fine :)
I've got the patch to do multiple listeners off one Listen directive in my 
tree and tested, but I'm currently swamped with other stuff.

I'll also take a look at this patch for getnameinfo() when I commit the other 
portions.  Thanks for the feedback!  -- justin

Re: Darwin and IPv6 was Re: cvs commit: httpd-2.0/server listen.c

[Colm MacCarthaigh,,,]

On Thu, Aug 14, 2003 at 05:48:38PM -0400, John K. Sterling wrote:
> On Thursday, August 14, 2003, at 05:20 PM, Colm MacCarthaigh,,, wrote:
> 
> >Can you just confirm it's listening in v6 only ? the output of
> >"netstat -an | grep LISTEN" (Darwin has netstat and grep, right?)
> >should be enough.
> 
> heh.  very funny:
> 
> % netstat -an | grep LISTEN
> tcp46  0  0  *.80   *.*
> LISTEN

good good, patch works so :) In which I'll now cc [EMAIL PROTECTED] and include 
the neccessary autoconf voodoo to fix OSX/Darwin.

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/
Index: configure.in
===
RCS file: /home/cvspublic/apr/configure.in,v
retrieving revision 1.531
diff -u -r1.531 configure.in
--- configure.in11 Aug 2003 17:40:38 -  1.531
+++ configure.in14 Aug 2003 22:40:37 -
@@ -1778,17 +1778,6 @@
 fi ],
   [ user_disabled_ipv6=0 ] )
 
-case $host in
-  *apple-darwin*)
-# It appears that Jaguar has all the right features, but
-# getnameinfo() fails to find the hostname for a mapped
-# address.
-broken_ipv6=1
-;;
-  *)
-broken_ipv6=0
-esac
-
 AC_SEARCH_LIBS(getaddrinfo, socket inet6)
 AC_SEARCH_LIBS(gai_strerror, socket inet6)
 AC_SEARCH_LIBS(getnameinfo, socket inet6)
@@ -1803,23 +1792,19 @@
 if test "$user_disabled_ipv6" = 1; then
 AC_MSG_RESULT([no -- disabled by user])
 else
-if test "x$broken_ipv6" = "x0"; then
-if test "x$have_sockaddr_in6" = "x1"; then
-if test "x$ac_cv_working_getaddrinfo" = "xyes"; then
-if test "x$ac_cv_working_getnameinfo" = "xyes"; then
-have_ipv6="1"
-AC_MSG_RESULT([yes])
-else
-AC_MSG_RESULT([no -- no getnameinfo])
-fi
+if test "x$have_sockaddr_in6" = "x1"; then
+if test "x$ac_cv_working_getaddrinfo" = "xyes"; then
+if test "x$ac_cv_working_getnameinfo" = "xyes"; then
+have_ipv6="1"
+AC_MSG_RESULT([yes])
 else
-AC_MSG_RESULT([no -- no working getaddrinfo])
+AC_MSG_RESULT([no -- no getnameinfo])
 fi
 else
-AC_MSG_RESULT([no -- no sockaddr_in6])
+AC_MSG_RESULT([no -- no working getaddrinfo])
 fi
 else
-AC_MSG_RESULT([no -- the platform has problems supporting IPv6])
+AC_MSG_RESULT([no -- no sockaddr_in6])
 fi
 fi
 
Index: network_io/unix/sockaddr.c
===
RCS file: /home/cvspublic/apr/network_io/unix/sockaddr.c,v
retrieving revision 1.41
diff -u -r1.41 sockaddr.c
--- network_io/unix/sockaddr.c  14 Aug 2003 17:36:17 -  1.41
+++ network_io/unix/sockaddr.c  14 Aug 2003 22:40:38 -
@@ -634,9 +634,28 @@
  * a numeric address string if it fails to resolve the host name;
  * that is *not* what we want here
  */
+#ifdef DARWIN && APR_HAVE_IPV6
+/* Darwin's getnameinfo does not work for IPv4-mapped-IPv6 addresses,
+ * the workaround is to convert the last 32 bits of the IPv6 address 
+ * to a valid sockaddr_in structure. This is extremely hacky, avoid
+ * re-use. */
+if (sockaddr->family == AF_INET6 && 
IN6_IS_ADDR_V4MAPPED(&sockaddr->sa.sin6.sin6_addr))
+{
+struct apr_sockaddr_t tmpsa;
+
+tmpsa.sa.sin.sin_family = AF_INET;
+tmpsa.sa.sin.sin_addr.s_addr = ((uint32_t *)sockaddr->ipaddr_ptr)[3]; 
+
+rc = getnameinfo((const struct sockaddr *)&tmpsa.sa, sizeof(struct 
sockaddr_in),
+ tmphostname, sizeof(tmphostname), NULL, 0,
+ flags != 0 ? flags : NI_NAMEREQD);
+}
+else
+#endif
 rc = getnameinfo((const struct sockaddr *)&sockaddr->sa, sockaddr->salen,
  tmphostname, sizeof(tmphostname), NULL, 0,
  flags != 0 ? flags : NI_NAMEREQD);
+
 if (rc != 0) {
 *hostname = NULL;
 

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

[Brad Nicholes]

   I couldn't answer that question for sure.  Taking a quick look
through the Apache code and modules, I don't see anything.  But that
doesn't mean that some third party module doesn't depend on it.  Do the
recent changes, include allowing sa->hostname to be NULL where it didn't
before?

  From what I see in CVS now, there is only one implementation of
apr_sockaddr_info_get() which is in unix/sockaddr.c.  This calls one of
two implementation of find_addresses() (whether you have getaddrinfo()
or not).  This is where sa->hostname is being defaulted to "0.0.0.0" (
in the non-getaddrinfo() implementation).  It seems that both
implementations should be sync'ed up to produce the same results.  It
appears that defaulting to "0.0.0.0" rather than NULL would be the safer
thing to do.

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> [EMAIL PROTECTED] Wednesday, August 13, 2003 4:18:19 PM >>>
--On Wednesday, August 13, 2003 16:07:12 -0600 Brad Nicholes 
<[EMAIL PROTECTED]> wrote:

>I guess I don't follow here.  The problem I have is that
> alloc_listener() allows "addr" to be NULL.  Because of the lame

Okay, let me try to restate the problem:

- addr *may* be NULL when alloc_listener is invoked.  Adding a NULL
check 
before doing the strcmp would indeed fix this problem, but prevents 
listener reuse.

- We *have* to pass NULL to apr_sockaddr_info_get so that getaddrname()
can 
do the IPv6/IPv4 fail-over on its own (as it is supposed to do - httpd

can't do the guessing correctly).

- However, on *some* implementations (based on the code in CVS right
now), 
the sa->hostname returned by apr_sockaddr_info_get may be NULL or
"0.0.0.0" 
even if we passed NULL into apr_sockaddr_info_get.

What we're trying to accomplish in this code fragment is to reuse old 
walkers that are already listening on the same port.  So, this 
inconsistency means that an addr with a value of NULL *could* be
equivalent 
to NULL or "0.0.0.0" (if the OS doesn't have IPv6).  So, one of two
things 
should happen:

- We should allow NULLs in sa->hostname.  We fix up the IPv4
implementation 
to not store "0.0.0.0" in the sa->hostname field, but NULL.

- We don't allow NULLs in sa->hostname.  Then, we need to take the
'name' 
returned by getaddrinfo() and store it.  However, we would have to do
this 
resolution before we can do the walking as NULL may resolve to (say): 
'0.0.0.0' or '::'.  Only after calling apr_sockaddr_info_get would we
know 
which it resolves to.

My question was whether anything relies upon sa->hostname being a valid

value?  I don't think they should, but the sockaddr_t is part of the
public 
conn_rec.  -- justin

Re: Darwin and IPv6 was Re: cvs commit: httpd-2.0/server listen.c

[John K . Sterling]

On Thursday, August 14, 2003, at 05:20 PM, Colm MacCarthaigh,,, wrote:

Can you just confirm it's listening in v6 only ? the output of
"netstat -an | grep LISTEN" (Darwin has netstat and grep, right?)
should be enough.
heh.  very funny:

% netstat -an | grep LISTEN
tcp46  0  0  *.80   *.*
LISTEN

stacking handlers in apache 1.3

[Bert Radke]

Hi,

is it possible to 'stack' handlers?
What I'm trying to do is to have 2 handlers for one location. The first 
handler gets a try
on the request and decides on some internal criteria if it processes the 
request or if the
other handler schould process it. The first handler ist implemented as a 
modul by myself.

How can I pass the processing from one handler to the next? I tried to 
return a
DECLINED in the hope the request would than passed on to the next 
handler, but aparantly
apache then tries to read the file '/location', insteed of 
calling the next handler for this
location.

I tried to do this in the request handler and in the 'post read_request 
handling', but with no luck..

I example code I've seen that one could set the handler for a request 
directly
(r->handler = 'test_handler'), but I could not figure out how to do this.

Thanks in advance for any help, links,...

Bert

Re: Darwin and IPv6 was Re: cvs commit: httpd-2.0/server listen.c

[Colm MacCarthaigh,,,]

On Thu, Aug 14, 2003 at 04:56:48PM -0400, John K. Sterling wrote:
> Hi Colm -
> 
> I'm not sure what to be looking for, but i applied your patch, rebuilt 
> (with the broken_ipv6 set to 0, of course), turned on HostnameLookups, 
> and my access logs have remote hostname properly resolved.  

That should mean it's working fine :)

> I'm running 
> Darwin Kernel Version 6.6.  Let me know if you want me to try out 
> anything else.

Can you just confirm it's listening in v6 only ? the output of
"netstat -an | grep LISTEN" (Darwin has netstat and grep, right?)
should be enough.

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/

Re: Darwin and IPv6 was Re: cvs commit: httpd-2.0/server listen.c

[John K . Sterling]

On Thursday, August 14, 2003, at 03:55 PM, Colm MacCarthaigh,,, wrote:

Patch attached. Since I havnt got a DARWIN machine to test on I
can't confirm it works, but it should. It works on Linux anyway
(not that it needs to).
Darwin might need some slightly different sa.[members] set to make
getnameinfo work but it shouldnt be anything major. If someone
with a darwin box could try it out I'd be much obliged. Turn
HostnameLookups On to get an idea as to whether it's working or
not.
Hi Colm -

I'm not sure what to be looking for, but i applied your patch, rebuilt 
(with the broken_ipv6 set to 0, of course), turned on HostnameLookups, 
and my access logs have remote hostname properly resolved.  I'm running 
Darwin Kernel Version 6.6.  Let me know if you want me to try out 
anything else.

sterling

Re: Darwin and IPv6 was Re: cvs commit: httpd-2.0/server listen.c

[Colm MacCarthaigh,,,]

On Thu, Aug 14, 2003 at 09:14:35AM -0700, Justin Erenkrantz wrote:
> - Trim IPv6 addresses from getaddrinfo()'s return values if APR_HAVE_IPV6 
> is 0.
>
>  (Perhaps only allow PF_INET sockets values to go in there.)
> 
> - Re-enable IPv6 on Darwin, and try to come up with a better solution to 
> the problem proposed last October.  (I proposed this before, but no one was 
> interested.)

Both these things really need to happen. The first is relatively
trivial:

Index: sockaddr.c
===
RCS file: /home/cvspublic/apr/network_io/unix/sockaddr.c,v
retrieving revision 1.40
diff -u -r1.40 sockaddr.c
--- sockaddr.c  14 Aug 2003 00:09:28 -  1.40
+++ sockaddr.c  14 Aug 2003 16:39:47 -
@@ -599,6 +599,9 @@
 if (flags & APR_IPV6_ADDR_OK) {
 return APR_ENOTIMPL;
 }
+if (family == AF_UNSPEC) {
+family = AF_INET:
+}
 #endif
 }
 

.. or similar. The darwin one is complicated, but I know of at least
3 people running Apache on Darwin for months, all they've been doing
is changing v6_broken to 0 in the apr configure script ;)

Until a truly AF agnostic ACL implementation can be used (see 
http://www.stdlib.net/~colmmacc/nsd/subnet.h and the accomponying
subnet.c for a rough idea) the Darwin problem should be solveable
by checking the IN6_IS_ADDR_V4MAPPED macro, and if so ignoring
the first 96 bytes and passing the last 32 on.

> And, I'm not sure if this is expected or not, but binding to the IPv6 
> address on my Darwin box does *not* bind to the IPv4 interface.  In order 
> to do that, we'd have to bind to each address returned from getaddrinfo().  

This is the bug I was trying to get accross (badly) the day before
yesterday. The fact that getaddrinfo returns a linked list is pretty
much ignored by alloc_listener :(

> Try out:
> 
> http://www.apache.org/~jerenkrantz/getaddr.c

That has a a bug of it's own :)

--- getaddr.c   Thu Aug 14 17:12:10 2003
+++ getaddr-new.c   Thu Aug 14 17:58:22 2003
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 
 int main() {
 struct addrinfo hints, *res, *res0;
@@ -42,7 +43,7 @@
 s = -1;
 continue;
 }
-if (accept(s, &client, &addrlen) < 0) {
+if (accept(s, res->ai_addr, &res->ai_addrlen) < 0) {
 cause = "accept";
 printf("%s %d\n", cause, errno);
 close(s);

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/

[patch] adding mpm info to httpd -V

[Geoffrey Young]

this came up on test-dev@ a while ago.  while we haven't quite fully settled 
on an interface to Apache-Test yet, I thought to post this patch here, since 
it implements some XXX comments in core.  the output for the prefork and 
worker builds I have look like

Server version: Apache/2.1.0-dev
Server built:   Aug 12 2003 02:25:22
Server's Module Magic Number: 20030213:1
Architecture:   32-bit
Server MPM: Prefork
  threaded: no
forked: yes (dynamic)
Server compiled with
Server version: Apache/2.1.0-dev
Server built:   Aug 12 2003 02:28:54
Server's Module Magic Number: 20030213:1
Architecture:   32-bit
Server MPM: Worker
  threaded: yes (static)
forked: yes (dynamic)
Server compiled with
--Geoff

Index: server/main.c
===
RCS file: /home/cvspublic/httpd-2.0/server/main.c,v
retrieving revision 1.144
diff -u -r1.144 main.c
--- server/main.c   22 Feb 2003 14:32:39 -  1.144
+++ server/main.c   13 Aug 2003 14:27:59 -
@@ -85,7 +85,40 @@
  * Most significant main() global data can be found in http_config.c
  */
-/* XXX - We should be able to grab the per-MPM settings here too */
+static void show_mpm_settings(void)
+{
+int mpm_query_info;
+
+printf("Server MPM: %s\n", ap_show_mpm());
+
+ap_mpm_query(AP_MPMQ_IS_THREADED, &mpm_query_info);
+
+printf("  threaded: ");
+
+if (mpm_query_info == AP_MPMQ_DYNAMIC) {
+printf("yes (dynamic)\n");
+}
+else if (mpm_query_info == AP_MPMQ_STATIC) {
+printf("yes (static)\n");
+}
+else {
+printf("no\n");
+}
+
+ap_mpm_query(AP_MPMQ_IS_FORKED, &mpm_query_info);
+printf("forked: ");
+
+if (mpm_query_info == AP_MPMQ_DYNAMIC) {
+printf("yes (dynamic)\n");
+}
+else if (mpm_query_info == AP_MPMQ_STATIC) {
+printf("yes (static)\n");
+}
+else {
+printf("no\n");
+}
+}
+
 static void show_compile_settings(void)
 {
 printf("Server version: %s\n", ap_get_server_version());
@@ -98,6 +131,9 @@
  * consistent
  */
 printf("Architecture:   %ld-bit\n", 8 * (long)sizeof(void *));
+
+show_mpm_settings();
+
 printf("Server compiled with\n");
 #ifdef BIG_SECURITY_HOLE
 printf(" -D BIG_SECURITY_HOLE\n");

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

[Justin Erenkrantz]

--On Wednesday, August 13, 2003 16:07:12 -0600 Brad Nicholes 
<[EMAIL PROTECTED]> wrote:

   I guess I don't follow here.  The problem I have is that
alloc_listener() allows "addr" to be NULL.  Because of the lame
Okay, let me try to restate the problem:

- addr *may* be NULL when alloc_listener is invoked.  Adding a NULL check 
before doing the strcmp would indeed fix this problem, but prevents 
listener reuse.

- We *have* to pass NULL to apr_sockaddr_info_get so that getaddrname() can 
do the IPv6/IPv4 fail-over on its own (as it is supposed to do - httpd 
can't do the guessing correctly).

- However, on *some* implementations (based on the code in CVS right now), 
the sa->hostname returned by apr_sockaddr_info_get may be NULL or "0.0.0.0" 
even if we passed NULL into apr_sockaddr_info_get.

What we're trying to accomplish in this code fragment is to reuse old 
walkers that are already listening on the same port.  So, this 
inconsistency means that an addr with a value of NULL *could* be equivalent 
to NULL or "0.0.0.0" (if the OS doesn't have IPv6).  So, one of two things 
should happen:

- We should allow NULLs in sa->hostname.  We fix up the IPv4 implementation 
to not store "0.0.0.0" in the sa->hostname field, but NULL.

- We don't allow NULLs in sa->hostname.  Then, we need to take the 'name' 
returned by getaddrinfo() and store it.  However, we would have to do this 
resolution before we can do the walking as NULL may resolve to (say): 
'0.0.0.0' or '::'.  Only after calling apr_sockaddr_info_get would we know 
which it resolves to.

My question was whether anything relies upon sa->hostname being a valid 
value?  I don't think they should, but the sockaddr_t is part of the public 
conn_rec.  -- justin

Re: [PATCH] Default Listen with IPv6 enabled incorrect

[Colm MacCarthaigh,,,]

(Cc:ing [EMAIL PROTECTED] now, because of APR patch)

On Tue, Aug 12, 2003 at 10:12:45AM -0700, Justin Erenkrantz wrote:
> --On Tuesday, August 12, 2003 5:58 PM +0100 "Colm MacCarthaigh,,," 
> <[EMAIL PROTECTED]> wrote:
> 
> >Even lo0 ? That's hard ;)
> 
> % ifconfig -a6
> %

As an asside I maintain that this is a broken system configuration, it's 
just as if you had IPv4 built in, but chose not to configure any IPv4 
addresses. What would have Apache do in such a situation ? Surely exiting 
is appropriate ...

But since you're less wrong than I am on this one, using AI_ADDRCONFIG
is best. This will weed out the problem.

But just to make clear I think "Listen 80" *really* needs to mean 
"Listen on port 80", not "Listen on port 80 in IPv4 only" :)

> >if getaddrinfo for PF_UNSPEC returns '::' in this situation
> >then it's really a lib(c|socket|nsl) bug, it does this on
> >Linux aswell, but the KAME implementation (and I believe windows)
> >have it fixed.
> 
> No, the OS is not returning '::'.  We're not using PF_UNSPEC, but 
> hard-coding PF_INET6.  (AF_INET6, AP_INET6, whatever the #define is.)

This is the real bug, Apache shouldnt be second-guessing getaddrinfo,
APR's call_resolver is an excellent example of how to do it properly,
AI_ADDRCONFIG is the key. Trouble is apr_sockaddr_info_get isnt 
calling it for us. This is an APR bug, see the attached patch.

> In alloc_listener, we're hardcoding '::' and PF_INET6 unconditionally if 
> the OS supports IPv6 (as determined by find_default_family).  (See the 
> !addr branch.)

It's not as broken as it seems, it does:

254   apr_sockaddr_info_get(&sa, NULL, APR_INET6, 0, 0, p) == APR_SUCCESS

So it *should* be valid. Problem is it *always* returns APR_SUCCESS
for a NULL hostname :(  Line 583 of apr/network_io/unix/sockaddr.c
is the real problem.

> I have a hunch that we may be able to create ephemeral ports (NULL address 
> passed in) without a configured IPv6 interface on Solaris.  Which strikes 
> me as not being totally wrong on Solaris's part.
> 
> I still maintain that my patch should be applied.  Let PF_UNSPEC figure it 
> out.

But your patch didnt do this, it just blindly returned 0.0.0.0. This
would break literally hundreds of peoples configs!

APR patch attached, it should fix your problem. I don't
have any systems I can configure easily into the state you
describe, so I can't test it properly just yet.

What should happen:
apr_sockaddr_info will call find_addresses, which will call
call_resolver which will have AI_ADDRCONFIG dutifuly set. So
if apply the patch , the problem should go away.

This all leaves listen.c bigger than it needs to be. So there's
changes in the patch for that too. The original find_default_family
didnt even compile for me anyway ;) The changes to listen.c create
one very slight logic problem in that:

 "Listen 80
  Listen 0.0.0.0 80"

will now result in a failure of apache to start because binding
to the socket twice will fail, wheras previously the dupe would
have been cought. I don't think this is a major problem.

Now, the extra cookie that we all deserve. This all shows up
a massive problem with apr_socket_create, it only creates
one socket. But apr_sockaddr_info_get returns a linked
list to many. It's allowable for AI_PASSIVE to return both
:: and 0.0.0.0, for example, or for round-robin DNS records
to return multiple addresses and this isnt handled properly.
My head hurts already.

There really needs to be an APR call that means: "walk this
linked list and creete/bind sockets for each node."

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/
Index: server/listen.c
===
RCS file: /home/cvspublic/httpd-2.0/server/listen.c,v
retrieving revision 1.86
diff -u -r1.86 listen.c
--- server/listen.c 31 Mar 2003 04:30:38 -  1.86
+++ server/listen.c 13 Aug 2003 00:45:02 -
@@ -235,38 +235,6 @@
 }
 
 
-static void find_default_family(apr_pool_t *p)
-{
-#if APR_HAVE_IPV6
-/* We know the platform supports IPv6, but this particular
- * system may not have IPv6 enabled.  See if we can get an
- * AF_INET6 socket and bind to an ephemeral port.  (On most
- * systems, getting an AF_INET6 socket is a sufficient test.
- * On certain levels of OpenUNIX, getting the socket is
- * successful but bind always returns ENETUNREACH.)
- */
-if (default_family == APR_UNSPEC) {
-apr_status_t sock_rv;
-apr_socket_t *tmp_sock;
-apr_sockaddr_t *sa;
-
-if ((sock_rv = apr_socket_create(&tmp_sock, APR_INET6, SOCK_STREAM, p)) 
-== APR_SUCCESS &&
-apr_sockaddr_info_get(&sa, NULL, APR_INET6, 0, 0, p) == APR_SUCCESS &&
-apr_bind(tmp_sock, sa) == APR_SUCCESS) { 
-default_family = APR_INET6;
-}
-else {
-default_family = APR_INET;
-

Re: [PATCH] Default Listen with IPv6 enabled incorrect

[Colm MacCarthaigh,,,]

On Mon, Aug 11, 2003 at 07:28:20PM -0700, Justin Erenkrantz wrote:
> Listen 8080

If IPv6 has been enabled, that should bind to :: , this is the standard
behaviour of all IPv6 apps, and to not do so would be utterly broken.
If by some quirk the OS doesnt support IPv4 over IPv6 sockets, then
getaddrinfo PF_UNSPEC magic should return the correct linked list to
handle this.

Changing this would break a lot of existing installs on people!

> Any arguments on tossing the find_default_family function altogether, and
> just going to 0.0.0.0 when the addr isn't specified?  If you want IPv6, you
> should explicitly specify it with 'Listen ::8080' or something, 

This would be a bug. It's not like IPv6 is an optional extra!

> but
> assuming that since we have IPv6 available that the unqualified addresses
> must be IPv6 doesn't make sense and is badness.  -- justin

I think you this 100% the wrong way around. It's extreme goodness,

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/

Re: [PATCH] Default Listen with IPv6 enabled incorrect

[Justin Erenkrantz]

--On Tuesday, August 12, 2003 5:58 PM +0100 "Colm MacCarthaigh,,," 
<[EMAIL PROTECTED]> wrote:

Even lo0 ? That's hard ;)
% ifconfig -a6
%
if getaddrinfo for PF_UNSPEC returns '::' in this situation
then it's really a lib(c|socket|nsl) bug, it does this on
Linux aswell, but the KAME implementation (and I believe windows)
have it fixed.
No, the OS is not returning '::'.  We're not using PF_UNSPEC, but hard-coding 
PF_INET6.  (AF_INET6, AP_INET6, whatever the #define is.)

In alloc_listener, we're hardcoding '::' and PF_INET6 unconditionally if the 
OS supports IPv6 (as determined by find_default_family).  (See the !addr 
branch.)

I have a hunch that we may be able to create ephemeral ports (NULL address 
passed in) without a configured IPv6 interface on Solaris.  Which strikes me 
as not being totally wrong on Solaris's part.

I still maintain that my patch should be applied.  Let PF_UNSPEC figure it 
out.  -- justin

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

[Justin Erenkrantz]

--On Wednesday, August 13, 2003 17:13:33 -0700 Justin Erenkrantz 
<[EMAIL PROTECTED]> wrote:

I just committed fixes to sync up the other way (NULL returns) and added
back the 'retry' logic if we have IPv6-enabled, but not configured (but
in a different way than before).
Looking at the original find_default_family code, it also tried to do a 
bind to see if IPv6 works just for 'certain levels of OpenUNIX.'  So, the 
socket() call would work on those OSes, but not later on when we try to 
bind to the socket.  (So it seems to me based on that comment.)

I guess what would make sense to me to do is to try the apr_bind() in that 
code segment where we create the socket on those releases of OpenUNIX with 
a platform-specific define.  If it works, close the socket, then recreate 
it.  (Ugh, but we're stretching for ideas here and doing the bind() for 
everyone seems, well, silly.)  But, I have no idea what 'OpenUNIX' is, nor 
how to test it.

Anyone with any thoughts?  (Solaris still works, FWIW.)  -- justin

Re: [PATCH] Default Listen with IPv6 enabled incorrect

[Justin Erenkrantz]

--On Tuesday, August 12, 2003 6:43 AM -0400 Jeff Trawick 
<[EMAIL PROTECTED]> wrote:

I wonder if this is related to Joe's recent change to
apr_sockaddr_info_get(), where IPv6 won't be returned if the system doesn't
support it.  Does reverting Joe's additional flag make any difference?
(AI_ADDRCONFIG)  It probably does, since ISTR we're specifying AF_UNSPEC for
the family, and family=AF_UNSPEC is where AI_ADDRCONFIG works its magic.
If you back out the AI_ADDRCONFIG flag, is Apache able to get an IPv6 socket
and handle incoming IPv4 connections when you have plain "listen ###"?
Nope.  I looked at that code bit and it doesn't execute.  When we enter that 
segment, we aren't AF_UNSPEC, but AF_INET6 because find_default_family thinks 
we have IPv6 available.  So, the AI_ADDRCONFIG code doesn't execute at all.

I guess find_default_family() has to make use of the fact that
getaddrinfo("::", AF_UNSPEC, AI_ADDRCONFIG) will fail now in some scenarios
where everything was happy before.
Nope, it's getaddrinfo('::', AF_INET6, 0) that causes the failure.  Are we 
sure that '::' is standard?  I couldn't find any documentation to support that.

It isn't quite that simple.  If there is a non-qualified address in the
config, we try to figure out if the box supports IPv6, and if it does then
we get an IPv6 listening socket for that port.
But, if the IPv6 fails, we should go back to IPv4.  Instead, we just exit.

Somehow I don't see the badness :)  The philosophy has been:

If your box is set up for IPv4+IPv6, Apache by default will handle
connections over either; if your box is set up for just IPv4, Apache by
default will notice that.  Isn't that goodness?
No.  Because it's broken.  ;-)

If the current problem is that find_default_family() needs to be smarter
since AI_ADDRCONFIG makes some of the IPv6 logic fail where it didn't fail
before, then let's make it smarter.
Nope.  find_default_family isn't really at fault.  Specifically, it is that:

getaddrinfo(NULL, AF_INET6, 0)

works on Solaris, but:

getaddrinfo('::', AF_INET6, 0)

returns the EAI 8 code.  find_default_family uses the first.  When no address 
is specified, the listener is attempted with the second.  And, when the second 
call fails, httpd just gives up rather than trying to fail back to IPv4.

I have no earthly idea why I'm only seeing this now.  Perhaps I never enabled 
IPv6 before now on Solaris.  -- justin

Re: trace segfault

[cmpilato]

solo turn <[EMAIL PROTECTED]> writes:

> with modules "dav", "dav_fs" and "dav_svn" loaded, apache2ctl graceful gives 
> sometimes:
> 
> [Wed Aug 06 19:07:53 2003] [notice] seg fault or similar nasty error detected in the 
> parent
>  process
> 
> how would you trace this to get more useful information what really
> happens?

Have you tried running 'httpd -X' under gdb?

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

[Colm MacCarthaigh,,,]

On Wed, Aug 13, 2003 at 03:18:19PM -0700, Justin Erenkrantz wrote:
> - addr *may* be NULL when alloc_listener is invoked.  Adding a NULL check 
> before doing the strcmp would indeed fix this problem, but prevents 
> listener reuse.

Since NULL only defines unqualified addresses, ie: "Listen 80" , any reuse 
on the same port will always fail. Would it be enough to simply do:

 if (sa) {
 apr_sockaddr_port_get(&oldport, sa);
- if (!strcmp(sa->hostname, addr) && port == oldport) {
+ if (( !addr || strcmp(sa->hostname, add)) && port == oldport) {
  /* re-use existing record */

After all, if someone did:

Listen 80

and then:

Listen 127.0.0.1 80

Shouldnt the original socket get re-used ? Or alternatively an error 
delivered.

> - We don't allow NULLs in sa->hostname.  Then, we need to take the 'name' 
> returned by getaddrinfo() and store it.  However, we would have to do this 
> resolution before we can do the walking as NULL may resolve to (say): 
> '0.0.0.0' or '::'.  Only after calling apr_sockaddr_info_get would we know 
> which it resolves to.

getaddrinfo won't return a 'name' in this situation though, even with
AI_CANONAME set for ai_flags. the v6 call_resolver would have to detect the
passive bind and hardcode '::' and '0.0.0.0' all over again :(

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/

Re: cvs commit: httpd-2.0/modules/ssl ssl_engine_kernel.c

[Jeff Trawick]

Sander Striker wrote:

Hmm. You have a request_rec there. How about:

  ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
"Encountered FakeBasicAuth spoof: %s", username);
Providing the request means that you get more information in the error_log.


Duh.  Thx,
Plz assume my +1 for APACHE_2_0_BRANCH is for the forthcoming rerror 
version :)

[PATCH] Default Listen with IPv6 enabled incorrect

[Justin Erenkrantz]

When I updated to HEAD just now on my Solaris box, httpd wouldn't start
with this:
[Mon Aug 11 19:10:08 2003] [crit] (EAI 8)host/servname not known:
alloc_listener: failed to set up sockaddr for ::
Syntax error on line 217 of .../conf/httpd.conf:
Listen setup failed
Line 217 is:

Listen 8080

Something that simple should work.  Yet, it looks like if we have IPv6
compiled in, we will assume that all non-qualified addresses are IPv6.
That seems wrong.  (I have no idea why this never appeared before.)
Any arguments on tossing the find_default_family function altogether, and
just going to 0.0.0.0 when the addr isn't specified?  If you want IPv6, you
should explicitly specify it with 'Listen ::8080' or something, but
assuming that since we have IPv6 available that the unqualified addresses
must be IPv6 doesn't make sense and is badness.  -- justin
Index: server/listen.c
===
RCS file: /home/cvs/httpd-2.0/server/listen.c,v
retrieving revision 1.86
diff -u -r1.86 listen.c
--- server/listen.c 31 Mar 2003 04:30:38 -  1.86
+++ server/listen.c 12 Aug 2003 02:22:34 -
@@ -235,38 +235,6 @@
}
-static void find_default_family(apr_pool_t *p)
-{
-#if APR_HAVE_IPV6
-/* We know the platform supports IPv6, but this particular
- * system may not have IPv6 enabled.  See if we can get an
- * AF_INET6 socket and bind to an ephemeral port.  (On most
- * systems, getting an AF_INET6 socket is a sufficient test.
- * On certain levels of OpenUNIX, getting the socket is
- * successful but bind always returns ENETUNREACH.)
- */
-if (default_family == APR_UNSPEC) {
-apr_status_t sock_rv;
-apr_socket_t *tmp_sock;
-apr_sockaddr_t *sa;
-
-if ((sock_rv = apr_socket_create(&tmp_sock, APR_INET6, 
SOCK_STREAM, p))
-== APR_SUCCESS &&
-apr_sockaddr_info_get(&sa, NULL, APR_INET6, 0, 0, p) == 
APR_SUCCESS &&
-apr_bind(tmp_sock, sa) == APR_SUCCESS) {
-default_family = APR_INET6;
-}
-else {
-default_family = APR_INET;
-}
-if (sock_rv == APR_SUCCESS) {
-apr_socket_close(tmp_sock);
-}
-}
-#endif
-}
-
-
static const char *alloc_listener(process_rec *process, char *addr, 
apr_port_t port)
{
ap_listen_rec **walk;
@@ -276,21 +244,10 @@
apr_sockaddr_t *sa;

if (!addr) { /* don't bind to specific interface */
-find_default_family(process->pool);
-switch(default_family) {
-case APR_INET:
-addr = "0.0.0.0";
-break;
-
-#if APR_HAVE_IPV6
-case APR_INET6:
-addr = "::";
-break;
-#endif
-
-default:
-ap_assert(1 != 1); /* should not occur */
-}
+/* We should default to IPv4 when we have no address specified
+ * even if we have IPv6.
+ */
+addr = "0.0.0.0";
}
/* see if we've got an old listener for this address:port */

Re: Darwin and IPv6 was Re: cvs commit: httpd-2.0/server listen.c

[Colm MacCarthaigh,,,]

On Thu, Aug 14, 2003 at 10:41:44AM -0700, Justin Erenkrantz wrote:
> --On Thursday, August 14, 2003 6:06 PM +0100 "Colm MacCarthaigh,,," 
> <[EMAIL PROTECTED]> wrote:
> 
> >Both these things really need to happen. The first is relatively
> >trivial:
> 
> Yup, I agree.  I committed a variant of this to the tree.  (The patch you 
> submitted would only execute if the APR_IPV4_ADDR_ONLY flag or whatever 
> would be passed in.)

Good good, silly me :)

> >Until a truly AF agnostic ACL implementation can be used (see
> >http://www.stdlib.net/~colmmacc/nsd/subnet.h and the accomponying
> >subnet.c for a rough idea) the Darwin problem should be solveable
> >by checking the IN6_IS_ADDR_V4MAPPED macro, and if so ignoring
> >the first 96 bytes and passing the last 32 on.
> 
> Hmm.  Would it be possible to submit a patch for this?  I'm not entirely 
> clear where this would go.

Patch attached. Since I havnt got a DARWIN machine to test on I
can't confirm it works, but it should. It works on Linux anyway
(not that it needs to).

Darwin might need some slightly different sa.[members] set to make
getnameinfo work but it shouldnt be anything major. If someone
with a darwin box could try it out I'd be much obliged. Turn
HostnameLookups On to get an idea as to whether it's working or
not.

Basically the patch spoofs enough of a valid _in v4 type structure
to make getnameinfo work, and grabs the address itself from the
appropriate place in the mapped one.

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/
Index: sockaddr.c
===
RCS file: /home/cvspublic/apr/network_io/unix/sockaddr.c,v
retrieving revision 1.41
diff -u -r1.41 sockaddr.c
--- sockaddr.c  14 Aug 2003 17:36:17 -  1.41
+++ sockaddr.c  14 Aug 2003 19:48:38 -
@@ -634,9 +634,28 @@
  * a numeric address string if it fails to resolve the host name;
  * that is *not* what we want here
  */
+#ifdef DARWIN && APR_HAVE_IPV6
+/* Darwin's getnameinfo does not work for IPv4-mapped-IPv6 addresses,
+ * the workaround is to convert the last 32 bits of the IPv6 address 
+ * to a valid sockaddr_in structure. This is extremely hacky, avoid
+ * re-use. */
+if (sockaddr->family == AF_INET6 && 
IN6_IS_ADDR_V4MAPPED(&sockaddr->sa.sin6.sin6_addr))
+{
+struct apr_sockaddr_t tmpsa;
+
+tmpsa.sa.sin.sin_family = AF_INET;
+tmpsa.sa.sin.sin_addr.s_addr = ((uint32_t *)sockaddr->ipaddr_ptr)[3]; 
+
+rc = getnameinfo((const struct sockaddr *)&tmpsa.sa, sizeof(struct 
sockaddr_in),
+ tmphostname, sizeof(tmphostname), NULL, 0,
+ flags != 0 ? flags : NI_NAMEREQD);
+}
+else
+#endif
 rc = getnameinfo((const struct sockaddr *)&sockaddr->sa, sockaddr->salen,
  tmphostname, sizeof(tmphostname), NULL, 0,
  flags != 0 ? flags : NI_NAMEREQD);
+
 if (rc != 0) {
 *hostname = NULL;
 

Re: mod_include: YABU (yet another bug uncovered)

[Brian Pane]

This appears to be due to the code at line ~2961 of
mod_include.c that tries to delete buckets from *bb
until it hits the bucket where the next tag starts.
In this test case, the bucket where the next tag
starts isn't in *bb at all; it's in ctx->ssi_tag_brigade.
I'm evaluating a couple of potential fixes; if I work
out something that looks correct, I'll post a patch.

Brian

On Thu, 2003-08-07 at 13:09, Ron Park wrote:
> Hi Again,
> 
> Well, we've come across another mod_include/cross brigade bug for which we
> currently don't yet have a patch (should have one soon but thought I'd give
> others a crack at it). :D
> 
> Here are two simple snippets, one which works, one which causes a core
> dump even with the latest patch of mod_include:
> 
> TrueSetFalseSetDone
> 
> TSetFalseSetDone
> 
> (The Cntl-P is to cause mod_bucketeer to fire off: need the following
> setting in your conf file to get this to work:
> 
> AddOutputFilter BUCKETEER;INCLUDES .html
> 
> Put each snippet in a file in your docroot, say, true.html and t.html and give
> them a try.
> 
> I'm pretty sure it's related to the code around line 491 of mod_include.c
> (at least that's the part that works differently for each one) but I haven't
> figured out how it's wrong.
> 
> Thanks,
> Ron

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

[John K . Sterling]

--On Wednesday, August 13, 2003 17:13:33 -0700 Justin Erenkrantz 
<[EMAIL PROTECTED]> wrote:

I just committed fixes to sync up the other way (NULL returns) and 
added
back the 'retry' logic if we have IPv6-enabled, but not configured 
(but
in a different way than before).
Hey Justin -

I'm still having problems with HEAD this morning on os X (Darwin Kernel 
Version 6.6) - is that expected?  (i'm not sure what the status is, but 
the above email implies a fix was applied).

(22)Invalid argument: make_sock: could not bind to address :80
no listening sockets available, shutting down
sterling

Re: [PATCH] Default Listen with IPv6 enabled incorrect

[Colm MacCarthaigh,,,]

On Tue, Aug 12, 2003 at 09:44:36AM -0700, Justin Erenkrantz wrote:
> --On Tuesday, August 12, 2003 5:33 PM +0100 "Colm MacCarthaigh,,," 
> <[EMAIL PROTECTED]> wrote:
> 
> >This is good though, if v6 is available and we can't listen there
> >then it should exit!
> 
> Let me re-state what I think the root cause of this is:
> 
> IPv6 stack is available on Solaris
> No IPv6 interfaces are currently configured

Even lo0 ? That's hard ;)

if getaddrinfo for PF_UNSPEC returns '::' in this situation
then it's really a lib(c|socket|nsl) bug, it does this on
Linux aswell, but the KAME implementation (and I believe windows)
have it fixed.

It's probably worth working around, but tbh I'd be of the opinion
that v6 not binding is just a serious an error as having v4 support
configured and not having any ipv4 addresses. It's very much a 
broken system configuration.

> So, IPv6 *could* be available, but it isn't.  I think we're making the 
> assumption that if the OS provides an IPv6 stack that we *must* use IPv6. 
> That seems broken.  We should intelligently fail-over to IPv4. 

That's the job of getaddrinfo. By rights getaddrinfo should be
clever enough to return the correct linked list no matter what.
Pity it isnt :/

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/

Re: ap_run_sub_req and content length

[Aryeh Katz]

> > I wrote here earlier about using ap_run_sub_req to send a response
> > to a client, and I receieved excellent advice, thank you. There is
> > one thing I was wondering. I see that the Encoding is chunked. I
> > would prefer to set the Content-Length to the correct length, rather
> > than use  chunked encoding. How can I do this (other than reading
> > the brigades, then running ap_set_content)?
> 
> You don't really have the ability to directly control this.
> 
> The content-length filter in combination with ap_set_keepalive
> determine whether chunking is used.  Generally speaking, if the first
> ap_pass_brigade call contains the EOS, Content-Length will be sent. 
Thanks.
Aryeh

---
Aryeh Katz
Secured-Services Inc.

Re: cvs commit: httpd-2.0/modules/dav/main mod_dav.c

[André Malo]

* Jeff Trawick wrote:

> [EMAIL PROTECTED] wrote:
>> nd  2003/08/06 07:46:48
>>
>>   Modified:.CHANGES
>>modules/dav/main mod_dav.c
>>   Log:
>>   use bucket brigades directly when reading PUT data. This avoids
>>   problems with content-length-modifying input filter (like deflate).
> 
>>   Index: mod_dav.c
>>   ===
>>   RCS file: /home/cvs/httpd-2.0/modules/dav/main/mod_dav.c,v
>>   retrieving revision 1.97
>>   retrieving revision 1.98
>>   diff -u -r1.97 -r1.98
>>   --- mod_dav.c  16 Jul 2003 06:31:53 -  1.97
>>   +++ mod_dav.c  6 Aug 2003 14:46:48 -   1.98
> 
>>   @@ -984,39 +979,61 @@
> ...
>>   +do {
>>   +apr_status_t rc;
>>   +
>>   +rc = ap_get_brigade(r->input_filters, bb,
>>   AP_MODE_READBYTES,
>>   +APR_BLOCK_READ, DAV_READ_BLOCKSIZE);
>>   +
>>   +if (rc != APR_SUCCESS) {
>>   +err = dav_new_error(r->pool,
>>   HTTP_INTERNAL_SERVER_ERROR, 0,
>>   +"Could not get next bucket
>>   brigade");
>>   +break;
> 
> don't we need to set keepalive flag to AP_CONN_CLOSE here and for any
> other error that causes us to stop reading the request body?

I thought, ap_status_drops_connection solves this automatically (for these
error codes)?

nd

Re: [PATCH] Default Listen with IPv6 enabled incorrect

[Colm MacCarthaigh,,,]

On Tue, Aug 12, 2003 at 09:04:05AM -0700, Justin Erenkrantz wrote:
> >If IPv6 has been enabled, that should bind to :: , this is the standard
> >behaviour of all IPv6 apps, and to not do so would be utterly broken.
> >If by some quirk the OS doesn't support IPv4 over IPv6 sockets, then
> >getaddrinfo PF_UNSPEC magic should return the correct linked list to
> >handle this.
> 
> Um, then wouldn't it only be listening on IPv6 sockets, not IPv4?

Yep :)

> Surely that can't be right.  -- justin

It is, in fact it's the only way you can do it on some stacks (Linux
is an example of one). The socket will accept IPv4 addresses and
treat them as IPv4 mapped IPv6 addresses. They look like:

:::193.1.219.90 

Apache handles these just fine for the most part, and the addresses
are translated into the correct AF for logging and so on. E.g on
Linux:

[EMAIL PROTECTED]:~$ netstat -an | grep 80
tcp0  0 :::80   :::*LISTEN   

byron:/home/colmmacc# tail -1 /var/log/apache/access.log
193.1.219.104 - - [15/May/2003:11:22:39 +0100] "GET / HTTP/1.0" 200 4110
"-" "check_http/1.32.2.6 (netsaint-plugins 1.2.9-4)"

Allthough on some platforms (Tru64) I'm tracking down a bug which
seems to leave the addresses mapped for variables like REMOTE_ADDR.

There's also some slight Access List type problems in that IPv4
ACLs don't get applied properly in some situations because of
this, and also mapped addresses in access lists never seem to work.
I can't allow/deny :::$something for example, which really
I should be able to.

I have an AF-indepentent access list implementation which I wrote
for NSD which I'm working on utilising in APR for apache which should
fix a lot of these niggly problems, but havnt had much time to work
on it lately.

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/

[STATUS] (httpd-2.1) Wed Aug 13 23:45:46 EDT 2003

[Rodent of Unusual Size]

APACHE 2.1 STATUS:  -*-text-*-
Last modified at [$Date: 2003/08/06 04:02:34 $]

Release [NOTE that only Alpha/Beta releases occur in 2.1 development]:

2.1.0   : in development

Please consult the following STATUS files for information
on related projects:

* srclib/apr/STATUS
* srclib/apr-util/STATUS
* docs/STATUS

Contributors looking for a mission:

* just do an egrep on "TODO" or "XXX" and see what's there


CURRENT RELEASE NOTES:


RELEASE SHOWSTOPPERS:

* Handling of non-trailing / config by non-default handler is broken
  http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105451701628081&w=2

* the edge connection filter cannot be removed 
  http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105366252619530&w=2

* bug in ap_get_client_block (wrong handling of EOS)
  http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105281649228629&w=2

CURRENT VOTES:

* Promote mod_cache from experimental to non-experimental
  status (keep issues noted below in EXPERIMENTAL MODULES as
  items to be addressed as a supported module).
  +1: jim, bnicholes
  -0: jerenkrantz
  -1: stoddard
  There are a couple of problems that need to be resolved
  before this module is moved out of experimental. 
  1) We need to at least review and comment on the RFC violations
  2) Resolve issue of how to cache page fragements (or perhaps -if- we
  want to cache page fragements). Today, mod_cache/mod_mem_cache
  will cache #include 'virtual' requests (but not #include 'file' 
  requests). This was accomplished by making CACHE_IN a
  CONTENT_SET-1 filter to force it to run before the SUBREQ_CORE
  filter.  But now responses cannot be cached that include the
  effects of having been run through CONTENT_SET filters
  (mod_deflate, mod_expires, etc).  We could rerun all the
  CONTENT_SET filters on the cached response, but this will not
  work in all cases. For example, mod_expires relies on installing
  the EXPIRATION filter during fixups. Contents served out of
  mod_cache (out of the quick_handler) bypass -all- the request
  line server hooks (Ryan really hated this. It is great for
  performance, but bad because of the complications listed above).
 

  jerenkrantz: There are a slew of RFC compliance bugs filed in Bugzilla
   for mod_cache (see 'RFC 2616 violations' below).  I think
   fixing them is a pre-requisite before it isn't experimental.

* httpd-std.conf and friends

  a) httpd-std.conf should be tailored by install (from src or
 binbuild) even if user has existing httpd.conf
 +1:   trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd,
   erikabele
   wrowe - prefer httpd.default.conf to avoid ambiguity with cvs

  b) tailored httpd-std.conf should be copied by install to
 sysconfdir/examples
 -0:   striker

  c) tailored httpd-std.conf should be installed to
 sysconfdir/examples or manualdir/exampleconf/
 +1:   slive, trawick, Ken, nd (prefer the latter), erikabele

  d) Installing a set of default config files when upgrading a server
 doesn't make ANY sense at all.
 +1:   ianh - medium/big sites don't use 'standard config' anyway, as it
  usually needs major customizations
 -1:   Ken, wrowe, jwoolley, jim, nd, erikabele
   wrowe - diff is wonderful when comparing old/new default configs,
   even for customized sites that ianh mentions
   jim - ... assuming that the default configs have been updated
 with the required inline docs to explain the
 changes

* If the parent process dies, should the remaining child processes
  "gracefully" self-terminate. Or maybe we should make it a runtime
  option, or have a concept of 2 parent processes (one being a 
  "hot spare").
  See: Message-ID: <[EMAIL PROTECTED]>

  Self-destruct: Ken, Martin, Lars
  Not self-destruct: BrianP, Ian, Cliff, BillS
  Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd

  /* The below was a concept on *how* to handle the problem */
  Have 2 parents: +1: jim
  -1: Justin, wrowe, rederpj, nd
  +0: Lars, Martin (while standing by, could it do
something useful?)

* Make the worker MPM the default MPM for threaded Unix boxes.
  +1:   Justin, Ian, Cliff, BillS, striker, wrowe, nd
  +0:   BrianP, Aaron (mutex contention is looking better with the
latest code, let's continue tuning and testing), rederpj, jim
  -0:   Lars

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

* Filter stacks and subrequests, redirects and fast redirects.
  There's at least on

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

[Brad Nicholes]

  This is looking much better.  At least we are not faulting anymore.  I
haven't been able to watch the code to make sure it is doing everything
else as expected, but it looks good so far.

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> [EMAIL PROTECTED] Wednesday, August 13, 2003 6:13:33 PM >>>
--On Wednesday, August 13, 2003 17:08:40 -0600 Brad Nicholes 
<[EMAIL PROTECTED]> wrote:

>   Right, so default to "::" for IPV6.  Either way, these two versions
of
> find_addresses() should be sync'ed up.

I just committed fixes to sync up the other way (NULL returns) and
added 
back the 'retry' logic if we have IPv6-enabled, but not configured (but
in 
a different way than before).

Please let me know how that works.  It works on Linux, and I'll test 
Solaris again.  -- justin

Re: stacking handlers in apache 1.3

[Bert Radke]

Sorry for bothering you,

It must have been to late yesterday.. I just found the solution. The 
trick is to
generate a subrequest und manipulate the handler there and run the 
subrequest
with ap_run_sub_req()...

Bert

Race conditions in restarts

[Joshua Slive]

Does anyone know if there are any race conditions left in the graceful
restart code?  If so, what are the details.

Does this section of documentation have any relevance in 2.0:
http://httpd.apache.org/docs-2.0/stopping.html#race

Joshua.

Re: File buckets v. core_output_filter

[Cliff Woolley]

On Sun, 10 Aug 2003, Bojan Smojver wrote:

> Just wanted to ask if you guys need me to open up a bug in Bugzilla for
> this?

No need... I'll be looking at it tomorrow.  If it were going to be
longer-term, I'd ask you to.  Thanks for the additional details and test
module!

--Cliff

RE: mod_include: YABU (yet another bug uncovered)

[Cliff Woolley]

On Thu, 7 Aug 2003, Ron Park wrote:

> The 'good' news is, there's two examples that show a core dumping
> problem. :)

Lovely.  :)

I'll add this to the test suite.

[PATCH] Add CookieIPHeader directive to mod_usertrack (for 1.3)

[Mike Cramer]

If apache is running behind a device which masks the client's IP address 
with its own, mod_usertrack will use this IP address as part of its 
cookie_id. Since this is NOT the actual IP address of the client (and 
may in fact be information best kept private), this behavior could be 
less than ideal.

Some devices (including a reverse-proxying Apache instance) set HTTP 
headers which contain the "real" IP address of the request, which might 
be more appropriate for mod_usertrack.

The attached patch adds the "CookieIPHeader" directive which takes as 
its only argument the name of the header containing the IP address to 
use. For example, mod_usertrack could use the IP address passed on my 
another Apache instance's "ProxyPass" with the following directive:

CookieIPHeader X-Forwarded-For

If the specified header doesn't exist or inet_aton() fails to parse it, 
the default value (from r->connection) is used instead. Without the 
directive, apache's behavior is unchanged.

This patch is against the mod_usertrack.c found in 1.3.28.

--
Mike Cramer
http://www.webkist.com/
--- mod_usertrack-orig.c2003-08-12 14:49:48.0 -0400
+++ mod_usertrack.c 2003-08-12 15:51:54.0 -0400
@@ -126,6 +126,7 @@
 char *cookie_name;
 char *cookie_domain;
 char *prefix_string;
+char *cookie_ip_header;
 } cookie_dir_rec;
 
 /* Define this to allow post-2000 cookies. Cookies use two-digit dates,
@@ -161,12 +162,26 @@
 
 long reqtime = (long) r->request_time;
 long clocktime;
+unsigned long ipaddr = 0;
+const char *rname = NULL;
 
-unsigned long ipaddr = ntohl(r->connection->remote_addr.sin_addr.s_addr);
-const char *rname = ap_get_remote_host(r->connection, r->per_dir_config,
-  REMOTE_NAME);
 dcfg = ap_get_module_config(r->per_dir_config, &usertrack_module);
 
+if (dcfg->cookie_ip_header != NULL) {
+   if (rname = ap_table_get(r->headers_in, dcfg->cookie_ip_header)) {
+struct in_addr remote_ip_addr;
+if (inet_aton(rname, &remote_ip_addr))
+   ipaddr = ntohl(remote_ip_addr.s_addr);
+   }
+}
+
+if (ipaddr == 0)
+   ipaddr = ntohl(r->connection->remote_addr.sin_addr.s_addr);
+
+if (rname == NULL)
+   rname = ap_get_remote_host(r->connection, r->per_dir_config,
+  REMOTE_NAME);
+
 #if defined(NO_GETTIMEOFDAY) && !defined(NO_TIMES)
 /* We lack gettimeofday(), so we must use time() to obtain the epoch
seconds, and then times() to obtain CPU clock ticks (milliseconds).
@@ -338,6 +353,7 @@
 dcfg->style = CT_UNSET;
 dcfg->format = CF_NORMAL;
 dcfg->enabled = 0;
+dcfg->cookie_ip_header = NULL;
 return dcfg;
 }
 
@@ -418,6 +434,14 @@
 return NULL;
 }
 
+static const char *set_cookie_ip(cmd_parms *cmd, void *mconfig, char *name)
+{
+cookie_dir_rec *dcfg = (cookie_dir_rec *) mconfig;
+
+dcfg->cookie_ip_header = ap_pstrdup(cmd->pool, name);
+return NULL;
+}
+
 static const char *set_cookie_name(cmd_parms *cmd, void *mconfig, char *name)
 {
 cookie_dir_rec *dcfg = (cookie_dir_rec *) mconfig;
@@ -528,6 +552,8 @@
  "'Normal' or 'Compact'"},
 {"CookiePrefix", set_cookie_prefix, NULL, OR_FILEINFO, TAKE1,
  "String prepended to cookie"},
+{"CookieIPHeader", set_cookie_ip, NULL, OR_FILEINFO, TAKE1,
+ "name of the header to use for client IP"},
 {NULL}
 };
 

Re: [PATCH] Default Listen with IPv6 enabled incorrect

[Jeff Trawick]

Justin Erenkrantz wrote:

When I updated to HEAD just now on my Solaris box, httpd wouldn't start
with this:
[Mon Aug 11 19:10:08 2003] [crit] (EAI 8)host/servname not known:
alloc_listener: failed to set up sockaddr for ::
I wonder if this is related to Joe's recent change to 
apr_sockaddr_info_get(), where IPv6 won't be returned if the system 
doesn't support it.  Does reverting Joe's additional flag make any 
difference?  (AI_ADDRCONFIG)  It probably does, since ISTR we're 
specifying AF_UNSPEC for the family, and family=AF_UNSPEC is where 
AI_ADDRCONFIG works its magic.

If you back out the AI_ADDRCONFIG flag, is Apache able to get an IPv6 
socket and handle incoming IPv4 connections when you have plain "listen 
###"?

I guess find_default_family() has to make use of the fact that 
getaddrinfo("::", AF_UNSPEC, AI_ADDRCONFIG) will fail now in some 
scenarios where everything was happy before.

Something that simple should work.  Yet, it looks like if we have IPv6
compiled in, we will assume that all non-qualified addresses are IPv6.
That seems wrong.  (I have no idea why this never appeared before.)
It isn't quite that simple.  If there is a non-qualified address in the 
config, we try to figure out if the box supports IPv6, and if it does 
then we get an IPv6 listening socket for that port.

Any arguments on tossing the find_default_family function altogether, and
just going to 0.0.0.0 when the addr isn't specified?  If you want IPv6, you
should explicitly specify it with 'Listen ::8080' or something, but
assuming that since we have IPv6 available that the unqualified addresses
must be IPv6 doesn't make sense and is badness.  -- justin
Somehow I don't see the badness :)  The philosophy has been:

If your box is set up for IPv4+IPv6, Apache by default will handle 
connections over either; if your box is set up for just IPv4, Apache by 
default will notice that.  Isn't that goodness?

If the current problem is that find_default_family() needs to be smarter 
since AI_ADDRCONFIG makes some of the IPv6 logic fail where it didn't 
fail before, then let's make it smarter.

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

[Brad Nicholes]

This change causes a problem on NetWare.  In the function
alloc_listener() before the change,  the code did not allow the variable
addr to be NULL.  In the changed code addr is allowed to be NULL which
means that the call to strcmp() after the call to
apr_sockaddr_port_get() causes NetWare to fault.

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> [EMAIL PROTECTED] Wednesday, August 13, 2003 1:17:45 PM >>>
jerenkrantz2003/08/13 12:17:45

  Modified:.CHANGES
   server   listen.c
  Log:
  Correct failure with Listen directives on machines with IPv6 enabled
by
  removing find_default_family() and letting APR determine what should
be done
  without a hostname.
  
  This patch requires the corollary APR patch to properly call
getaddrinfo().
  
  (Justin modified Colm's patch to always walk the old listeners even
when
  we have an address.  That part of the patch wasn't really relevant.)
  
  Submitted by: Colm MacCárthaigh <[EMAIL PROTECTED]>
  Reviewed by:  Justin Erenkrantz
  
  Revision  ChangesPath
  1.1251+3 -0  httpd-2.0/CHANGES
  
  Index: CHANGES
  ===
  RCS file: /home/cvs/httpd-2.0/CHANGES,v
  retrieving revision 1.1250
  retrieving revision 1.1251
  diff -u -u -r1.1250 -r1.1251
  --- CHANGES   12 Aug 2003 21:02:00 -  1.1250
  +++ CHANGES   13 Aug 2003 19:17:45 -  1.1251
  @@ -2,6 +2,9 @@
   
 [Remove entries to the current 2.0 section below, when
backported]
   
  +  *) Correct failure with Listen directives on machines with IPv6
enabled.
  + [Colm MacCárthaigh <[EMAIL PROTECTED]>, Justin Erenkrantz]
  +  
 *) Fix a link failure in mod_ssl when the OpenSSL libraries
contain
the ENGINE functions but the engine header files are missing.
[Cliff Woolley]
  
  
  
  1.87  +0 -50 httpd-2.0/server/listen.c
  
  Index: listen.c
  ===
  RCS file: /home/cvs/httpd-2.0/server/listen.c,v
  retrieving revision 1.86
  retrieving revision 1.87
  diff -u -u -r1.86 -r1.87
  --- listen.c  31 Mar 2003 04:30:38 -  1.86
  +++ listen.c  13 Aug 2003 19:17:45 -  1.87
  @@ -235,38 +235,6 @@
   }
   
   
  -static void find_default_family(apr_pool_t *p)
  -{
  -#if APR_HAVE_IPV6
  -/* We know the platform supports IPv6, but this particular
  - * system may not have IPv6 enabled.  See if we can get an
  - * AF_INET6 socket and bind to an ephemeral port.  (On most
  - * systems, getting an AF_INET6 socket is a sufficient test.
  - * On certain levels of OpenUNIX, getting the socket is
  - * successful but bind always returns ENETUNREACH.)
  - */
  -if (default_family == APR_UNSPEC) {
  -apr_status_t sock_rv;
  -apr_socket_t *tmp_sock;
  -apr_sockaddr_t *sa;
  -
  -if ((sock_rv = apr_socket_create(&tmp_sock, APR_INET6,
SOCK_STREAM, p)) 
  -== APR_SUCCESS &&
  -apr_sockaddr_info_get(&sa, NULL, APR_INET6, 0, 0, p) ==
APR_SUCCESS &&
  -apr_bind(tmp_sock, sa) == APR_SUCCESS) { 
  -default_family = APR_INET6;
  -}
  -else {
  -default_family = APR_INET;
  -}
  -if (sock_rv == APR_SUCCESS) {
  -apr_socket_close(tmp_sock);
  -}
  -}
  -#endif
  -}
  -
  -
   static const char *alloc_listener(process_rec *process, char *addr,
apr_port_t port)
   {
   ap_listen_rec **walk;
  @@ -274,24 +242,6 @@
   apr_status_t status;
   apr_port_t oldport;
   apr_sockaddr_t *sa;
  -
  -if (!addr) { /* don't bind to specific interface */
  -find_default_family(process->pool);
  -switch(default_family) {
  -case APR_INET:
  -addr = "0.0.0.0";
  -break;
  -
  -#if APR_HAVE_IPV6
  -case APR_INET6:
  -addr = "::";
  -break;
  -#endif
  -
  -default:
  -ap_assert(1 != 1); /* should not occur */
  -}
  -}
   
   /* see if we've got an old listener for this address:port */
   for (walk = &old_listeners; *walk; walk = &(*walk)->next) {
  
  
  

Re: mod_rewrite: different behaviour on sub-requests - Why?

[André Malo]

* Cliff Woolley wrote:

> On Wed, 6 Aug 2003, André Malo wrote:
> 
>> Hmm. After further thinking about it... I'm in favour of removing the
>> check in 2.1. But I wouldn't backport it, since it *may* lead to a
>> different behaviour of existing rules.
> 
> I'm leaning on leaving it as-is for that same reason unless there's a
> clear reason to change it...

The problem is, for example, that you cannot , since the subrequest won't be rewritten.
(Sure, this affects .htaccess rules only, but a lot of people don't have the
choice ...).

nd

RE: mod_include: YABU (yet another bug uncovered)

[Ron Park]

Oops, I may have sent this off too hurriedly; looks like both
example core... the first one wasn't coring when I used Cntl-B
instead of Cntl-P and I think my browser was caching it.

The 'good' news is, there's two examples that show a core dumping
problem. :)

Ron

> -Original Message-
> From: Ron Park [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, August 07, 2003 4:09 PM
> To: '[EMAIL PROTECTED]'
> Subject: mod_include: YABU (yet another bug uncovered)
> 
> 
> Hi Again,
> 
> Well, we've come across another mod_include/cross brigade bug 
> for which we
> currently don't yet have a patch (should have one soon but 
> thought I'd give
> others a crack at it). :D
> 
> Here are two simple snippets, one which works, one which causes a core
> dump even with the latest patch of mod_include:
> 
> True -->SetFalseSetDone
> 
> T -->SetFalseSetDone
> 
> (The Cntl-P is to cause mod_bucketeer to fire off: need the following
> setting in your conf file to get this to work:
> 
> AddOutputFilter BUCKETEER;INCLUDES .html
> 
> Put each snippet in a file in your docroot, say, true.html 
> and t.html and give
> them a try.
> 
> I'm pretty sure it's related to the code around line 491 of 
> mod_include.c
> (at least that's the part that works differently for each 
> one) but I haven't
> figured out how it's wrong.
> 
> Thanks,
> Ron
> 

Re: cvs commit: httpd-2.0/modules/mappers mod_rewrite.c

[Jeff Trawick]

[EMAIL PROTECTED] wrote:

  Index: mod_rewrite.c
  ===
  RCS file: /home/cvs/httpd-2.0/modules/mappers/mod_rewrite.c,v
  retrieving revision 1.218
  retrieving revision 1.219
  diff -u -r1.218 -r1.219
  --- mod_rewrite.c	4 Aug 2003 23:43:39 -	1.218
  +++ mod_rewrite.c	5 Aug 2003 12:12:21 -	1.219
  @@ -4659,6 +4659,16 @@
* +---+
*/
   
  +#ifdef REWRITELOG_DISABLED
  +static const char *fake_rewritelog(cmd_parms *cmd, void *dummy, const char *a1)
  +{
  +return "RewriteLog and RewriteLogLevel are not support by this incarnation "
  +   "of mod_rewrite, because it was compiled using the "
"are not supported by this build of mod_rewrite because..."

[STATUS] (apache-1.3) Wed Aug 13 23:45:18 EDT 2003

[Rodent of Unusual Size]

APACHE 1.3 STATUS:  -*-text-*-
  Last modified at [$Date: 2003/07/16 20:27:07 $]

Release:

   1.3.28: Tagged July 16, 2003.
   1.3.27: Tagged September 30, 2002. Announced Oct 3, 2002.
   1.3.26: Tagged June 18, 2002.
   1.3.25: Tagged June 17, 2002. Not released.
   1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002.
   1.3.23: Tagged Jan 21, 2002.
   1.3.22: Tagged Oct 8, 2001.  Announced Oct 12, 2001.
   1.3.21: Not released.
 (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001)
   1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001.
   1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001.
   1.3.18: Tagged and rolled Not released.
 (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001)
   1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001.
   1.3.16: Not released.
 (Pulled because of vhosting bug. t/r Jan 20, 2001)
   1.3.15: Not released.
 (Pulled due to CVS dumping core during the tagging when it
  reached src/os/win32/)
   1.3.14: Tagged and Rolled Oct 10, 2000.  Released/announced on the 13th.
   1.3.13: Not released.
 (Pulled in the "first minutes" due to a Netware build bug)
   1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th.
   1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st.
   1.3.10: Not released.
 (Pulled at "last minute" due to a build bug in the MPE port)
1.3.9: Tagged and rolled on Aug. 16, 1999. Released and announced on 19th.
1.3.8: Not released.
1.3.7: Not released.
1.3.6: Tagged and rolled on Mar. 22, 1999. Released and announced on 24th.
1.3.5: Not released.
1.3.4: Tagged and rolled on Jan. 9, 1999.  Released on 11th, announced on 12th.
1.3.3: Tagged and rolled on Oct. 7, 1998.  Released on 9th, announced on 10th.
1.3.2: Tagged and rolled on Sep. 21, 1998. Announced and released on 23rd.
1.3.1: Tagged and rolled on July 19, 1998. Announced and released.
1.3.0: Tagged and rolled on June 1, 1998.  Announced and released on the 6th.
   
2.0  : Available for general use, see httpd-2.0 repository

RELEASE SHOWSTOPPERS:

   None

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

   * Current vote on 3 PRs for inclusion:
  Bugz #17877 (passing chunked encoding thru proxy)
  (still checking if RFC compliant... vote is on the
   correctness of the patch code only).
+1: jim, chuck, minfrin
  Bugz #9181 (Unable to set headers on non-2XX responses)
+1: Martin, Jim
  Gnats #10246 (Add ProxyConnAllow directive)
+0: Martin (or rather -.5, see dev@ Message
<[EMAIL PROTECTED]>)

* htpasswd.c and htdigest.c use tmpnam()... consider using
  mkstemp() when available.
Message-ID: <[EMAIL PROTECTED]>
Status:

* Dean's "unescaping hell" (unescaping the various URI components
  at the right time and place, esp. unescaping the host name).
Message-ID: <[EMAIL PROTECTED]>
Status:

* Martin observed a core dump because a ipaddr_chain struct contains
  a NULL-"server" pointer when being dereferenced by invoking "httpd -S".
Message-ID: <[EMAIL PROTECTED]>
Status: Workaround enabled. Clean solution can come after 1.3.19

* long pathnames with many components and no AllowOverride None
  Workaround is to define  with AllowOverride None,
  which is something all sites should do in any case.
Status: Marc was looking at it.  (Will asks 'wasn't this patched?')

* Ronald Tschalär's patch to mod_proxy to allow other modules to
  set headers too (needed by mod_auth_digest)
Message-ID: <[EMAIL PROTECTED]>
Status:


Available Patches (Most likely, will be ported to 2.0 as appropriate):

   *  A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker
 <[EMAIL PROTECTED]> to more fully close some segfault potential.
Message-ID: <[EMAIL PROTECTED]>
Status:  Jim +1 (for 1.3.19), Martin +0

* Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires
Message-ID: <[EMAIL PROTECTED]>
Status: Martin +1, Jim +1, Ken +1 (on concept)

* Raymond S Brand's path to mod_autoindex to fix the header/readme
  include processing so the envariables are correct for the included
  documents.  (Actually, there are two variants in the patch message,
  for two different ways of doing it.)
Message-ID: <[EMAIL PROTECTED]>
Status: Martin +1(concept)

* Jayaram's patch (10/27/99) for bugfix to mod_autoindex
  IndexIgnore  should hide the files with this file-
  extension in directory listings. This was NOT happening because the 
  total filename was being compared with the file-extension.
  Status: Martin +1(untested), Ken +1(untested)
   
* Salvador Ortiz Garcia <

ap_run_sub_req and content length

[Aryeh Katz]

I wrote here earlier about using ap_run_sub_req to send a response to a 
client, and I receieved excellent advice, thank you.
There is one thing I was wondering.
I see that the Encoding is chunked.
I would prefer to set the Content-Length to the correct length, rather than use 
chunked encoding.
How can I do this (other than reading the brigades, then running 
ap_set_content)?
Aryeh
---
Aryeh Katz
Secured-Services Inc.

Re: cvs commit: httpd-2.0/modules/mappers mod_rewrite.c

[Jeff Trawick]

André Malo wrote:
* Jeff Trawick wrote:


 +return "RewriteLog and RewriteLogLevel are not support by this
 incarnation "
 +   "of mod_rewrite, because it was compiled using the "
"are not supported by this build of mod_rewrite because..."


I thought, I'd be funny :-)
my main point was "supported" instead of "support", as Thom later 
pointed out :)

but "build" is probably more accurate than "incarnation"

Re: Using/citing Apache in book -- trademark/copyright?

[Cliff Woolley]

On Tue, 5 Aug 2003, Sujay Parekh wrote:

> My colleagues and I are writing a book in which reference will be made to
> the Apache Web Server (such as normally found in research papers, eg, "our

As a side note, the official name is "Apache HTTP Server" not "Apache Web
Server".

> I saw on your FAQ that we should use the wording "Apache is a trademark
> of The Apache Software Foundation, and is used with permission."

It also says: "This is not necessary in the case of all-inclusive
attribution language such as, 'All marks are the properties of their
respective owners.'"  That said, the board of the directors is the right
place to ask about this... they're the ones in charge of granting such
permissions.  Their email address is listed at:

http://www.apache.org/foundation/mailinglists.html#foundation-board

--Cliff

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

[Brad Nicholes]

   I guess I don't follow here.  The problem I have is that
alloc_listener() allows "addr" to be NULL.  Because of the lame
implementation of strcmp() on NetWare, this causes a fault  (The same
thing would happen if sa->hostname where NULL also in this function). 
Allowing sa->hostname to be NULL by definition is fine.  I just need to
make sure that functions like strcmp() don't get called with a NULL
value.  Therefore, in this particular case, either "addr" needs to be
initialized as it was before, or a check needs to be made before calling
strcmp().  I just don't know which is the correct behavior given the
refactoring of the code.

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> [EMAIL PROTECTED] Wednesday, August 13, 2003 3:44:52 PM >>>
--On Wednesday, August 13, 2003 15:14:40 -0600 Brad Nicholes 
<[EMAIL PROTECTED]> wrote:

> This change causes a problem on NetWare.  In the function
> alloc_listener() before the change,  the code did not allow the
variable
> addr to be NULL.  In the changed code addr is allowed to be NULL
which
> means that the call to strcmp() after the call to
> apr_sockaddr_port_get() causes NetWare to fault.

Hmm.  Now, I wonder how reliant we are upon the sockaddr_t having a 
non-NULL hostname field.  Are we going to be allowed to leave it NULL?

apr_sockaddr_info_get's documentation explicitly says it allows NULL 
inputs, but it doesn't say what the 'hostname' field will turn into.

The IPv4 apr_sockaddr_info_get impl. just hardcodes sa->hostname to be

"0.0.0.0", while the IPv6 branch (getaddrinfo impl) will leave it NULL.

So, we may not reuse listeners on IPv4 right now (NULL gets translated
into 
"0.0.0.0" and stored as that string in the sockaddr_t).  I guess I'll 
prefer to have the hostname be what we passed into
apr_sockaddr_info_get - 
that is the sa->hostname should be NULL even with IPv4
implementations.

Then, we'll have to fix up the references to sa->hostname to allow for
NULL 
values.

Thoughts?  Make sense?  -- justin

[STATUS] (apache-1.3) Wed Aug 6 23:45:12 EDT 2003

[Rodent of Unusual Size]

APACHE 1.3 STATUS:  -*-text-*-
  Last modified at [$Date: 2003/07/16 20:27:07 $]

Release:

   1.3.28: Tagged July 16, 2003.
   1.3.27: Tagged September 30, 2002. Announced Oct 3, 2002.
   1.3.26: Tagged June 18, 2002.
   1.3.25: Tagged June 17, 2002. Not released.
   1.3.24: Tagged Mar 21, 2002. Announced Mar 22, 2002.
   1.3.23: Tagged Jan 21, 2002.
   1.3.22: Tagged Oct 8, 2001.  Announced Oct 12, 2001.
   1.3.21: Not released.
 (Pulled for htdocs/manual config mismatch. t/r Oct 5, 2001)
   1.3.20: Tagged and rolled May 15, 2001. Announced May 21, 2001.
   1.3.19: Tagged and rolled Feb 26, 2001. Announced Mar 01, 2001.
   1.3.18: Tagged and rolled Not released.
 (Pulled because of an incorrect unescaping fix. t/r Feb 19, 2001)
   1.3.17: Tagged and rolled Jan 26, 2001. Announced Jan 29, 2001.
   1.3.16: Not released.
 (Pulled because of vhosting bug. t/r Jan 20, 2001)
   1.3.15: Not released.
 (Pulled due to CVS dumping core during the tagging when it
  reached src/os/win32/)
   1.3.14: Tagged and Rolled Oct 10, 2000.  Released/announced on the 13th.
   1.3.13: Not released.
 (Pulled in the "first minutes" due to a Netware build bug)
   1.3.12: Tagged and rolled Feb. 23, 2000. Released/announced on the 25th.
   1.3.11: Tagged and rolled Jan. 19, 2000. Released/announced on the 21st.
   1.3.10: Not released.
 (Pulled at "last minute" due to a build bug in the MPE port)
1.3.9: Tagged and rolled on Aug. 16, 1999. Released and announced on 19th.
1.3.8: Not released.
1.3.7: Not released.
1.3.6: Tagged and rolled on Mar. 22, 1999. Released and announced on 24th.
1.3.5: Not released.
1.3.4: Tagged and rolled on Jan. 9, 1999.  Released on 11th, announced on 12th.
1.3.3: Tagged and rolled on Oct. 7, 1998.  Released on 9th, announced on 10th.
1.3.2: Tagged and rolled on Sep. 21, 1998. Announced and released on 23rd.
1.3.1: Tagged and rolled on July 19, 1998. Announced and released.
1.3.0: Tagged and rolled on June 1, 1998.  Announced and released on the 6th.
   
2.0  : Available for general use, see httpd-2.0 repository

RELEASE SHOWSTOPPERS:

   None

RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:

   * Current vote on 3 PRs for inclusion:
  Bugz #17877 (passing chunked encoding thru proxy)
  (still checking if RFC compliant... vote is on the
   correctness of the patch code only).
+1: jim, chuck, minfrin
  Bugz #9181 (Unable to set headers on non-2XX responses)
+1: Martin, Jim
  Gnats #10246 (Add ProxyConnAllow directive)
+0: Martin (or rather -.5, see dev@ Message
<[EMAIL PROTECTED]>)

* htpasswd.c and htdigest.c use tmpnam()... consider using
  mkstemp() when available.
Message-ID: <[EMAIL PROTECTED]>
Status:

* Dean's "unescaping hell" (unescaping the various URI components
  at the right time and place, esp. unescaping the host name).
Message-ID: <[EMAIL PROTECTED]>
Status:

* Martin observed a core dump because a ipaddr_chain struct contains
  a NULL-"server" pointer when being dereferenced by invoking "httpd -S".
Message-ID: <[EMAIL PROTECTED]>
Status: Workaround enabled. Clean solution can come after 1.3.19

* long pathnames with many components and no AllowOverride None
  Workaround is to define  with AllowOverride None,
  which is something all sites should do in any case.
Status: Marc was looking at it.  (Will asks 'wasn't this patched?')

* Ronald Tschalär's patch to mod_proxy to allow other modules to
  set headers too (needed by mod_auth_digest)
Message-ID: <[EMAIL PROTECTED]>
Status:


Available Patches (Most likely, will be ported to 2.0 as appropriate):

   *  A rewrite of ap_unparse_uri_components() by Jeffrey W. Baker
 <[EMAIL PROTECTED]> to more fully close some segfault potential.
Message-ID: <[EMAIL PROTECTED]>
Status:  Jim +1 (for 1.3.19), Martin +0

* Andrew Ford's patch (1999/12/05) to add absolute times to mod_expires
Message-ID: <[EMAIL PROTECTED]>
Status: Martin +1, Jim +1, Ken +1 (on concept)

* Raymond S Brand's path to mod_autoindex to fix the header/readme
  include processing so the envariables are correct for the included
  documents.  (Actually, there are two variants in the patch message,
  for two different ways of doing it.)
Message-ID: <[EMAIL PROTECTED]>
Status: Martin +1(concept)

* Jayaram's patch (10/27/99) for bugfix to mod_autoindex
  IndexIgnore  should hide the files with this file-
  extension in directory listings. This was NOT happening because the 
  total filename was being compared with the file-extension.
  Status: Martin +1(untested), Ken +1(untested)
   
* Salvador Ortiz Garcia <

Re: About time to do 2.0.48?

[Cliff Woolley]

On Fri, 8 Aug 2003, Sander Striker wrote:

> I envision tagging somewhere next (mid) week, following
> release 1 or 2 weeks after that.

I'm starting to think it might be nice if we can push this back to say
Thursday instead of Tuesday-ish as was suggested last night... I rally
want to wrap these (now three) funky bucket problems (Bojan's, Ron's, and
Glenn's), and I just plain won't have time to work on them until Monday.

--Cliff

ssl/http test is failing

[Stas Bekman]

the ssl/http test is failing. it expect the server to send a normal 40x error 
response with the body, however it sends 200 and HTTP/0.9. there is an 
impedance mismatch here.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: mod_include: YABU (yet another bug uncovered)

[Cliff Woolley]

On Sat, 9 Aug 2003, Brian Pane wrote:

> This appears to be due to the code at line ~2961 of
> mod_include.c that tries to delete buckets from *bb
> until it hits the bucket where the next tag starts.
> In this test case, the bucket where the next tag
> starts isn't in *bb at all; it's in ctx->ssi_tag_brigade.

Doh.

> I'm evaluating a couple of potential fixes; if I work
> out something that looks correct, I'll post a patch.

Cool.  As long as it passes all of the perl framework test cases, then
it's fine by me.  :)

Thanks!
Cliff

Re: [Slightly OT] compiled source distribution question

[Cliff Woolley]

On Mon, 11 Aug 2003, Mark W. Webb wrote:

> If I compile apache, and distribute the binaries, are there any
> requirements on what I package in my application?  For instance, must I
> distribute the manual files that get installed when I perform a "make
> install" ?

The license tells you what the requirements are:

 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution,
 *if any, must include the following acknowledgment:
 *   "This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowledgment may appear in the software itself,
 *if and wherever such third-party acknowledgments normally appear.
 *
 * 4. The names "Apache" and "Apache Software Foundation" must
 *not be used to endorse or promote products derived from this
 *software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called "Apache",
 *nor may "Apache" appear in their name, without prior written
 *permission of the Apache Software Foundation.

--Cliff

[Slightly OT] compiled source distribution question

[Mark W. Webb]

If I compile apache, and distribute the binaries, are there any 
requirements on what I package in my application?  For instance, must I 
distribute the manual files that get installed when I perform a "make 
install" ?

thank you for the help in advance.


smime.p7s
Description: S/MIME Cryptographic Signature

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

[Colm MacCarthaigh,,,]

On Wed, Aug 13, 2003 at 11:30:04PM +0100, Colm MacCarthaigh,,, wrote:
> 
> After all, if someone did:
> 
> Listen 80
> 
> and then:
> 
> Listen 127.0.0.1 80
> 
> Shouldnt the original socket get re-used ? Or alternatively an error 
> delivered.

*actually thinks about it*

obviously then "Listen 127.0.0.1 80" followed by "Listen 80" wont work
in an acceptable manner. It really needs to bomb out if anything tries
to listen on the same port as a passive address.

-- 
Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
[EMAIL PROTECTED] http://www.stdlib.net/

Re: File buckets v. core_output_filter

[Cliff Woolley]

On Thu, 7 Aug 2003, Bill Stoddard wrote:

> I've not looked in core_output_filter for a while but I know in the past
>   the intent was to not use sf at all if more than one fd bucket was in
> the brigade. Maybe that's broken or intentionally changed...

Actually it's been that way since Ryan checked in rev 1.1 of
server/core.c.  Take a look at line 3905-3921 (for 2.0) or 3879-3898 (for
2.1).

--Cliff

Tracing dynamic content calls and subroutines for performance tuning

[Todd Weaver]

I use Linux Apache1.3/mod_perl/mason, dbd::mysql.

Is there a way to show a trace of an incoming request,
and ALL the components called (perl subroutines etc),
with their start times and end times.

(if there is no way, I am interested in authoring,
 with some guidance/assistance, a third party software to do so,
 so if anybody is interested, please let me know)

This information would help greatly with tracking down blocking,
or slow components.

An example output of what would be useful:
1. top-level-component.pl10ms
2.  header-component.pl  15ms
3.   navigation-component.pl 25ms
4.db-request-component.pl   300ms
5. html-output.pl75ms
6.  footer.pl10ms

I haven't seen anything that can do that, the closest thing was running an actual 
truss/strace/trace on a single process, which doesn't quite return what I am searching 
for (unless somebody knows how to tweak the output better than I), as well as it 
wouldn't be able to do this for all the development machine's requests
.

The intention would be to either log this information on a per request basis for a 
development machine, or possibly even displaying the information at the base of each 
page during development.

Re: anybody ever heard of a ProxyPassCookie patch

[Graham Leggett]

Jeff Trawick wrote:

and why it was never integrated into Apache 1.3?

It is described here:

http://www.wede.de/sw/mod_proxy/

There is also such a patch in the old bug db and at least one other open 
PR about the need for such a feature (updating domains in cookies during 
reverse proxy operations).

I didn't see any comments in the PRs about technical problems with such 
a feature, but I'm curious if anybody knows of some.
Such a feature would need to be configurable, as the change to the path
in the cookie might not necessarily be what the person intended.
For example:

ProxyPass /foo http://backend/

would cause the cookie backend path "/" to be changed to "/foo". The
user may want the cookie path to stay "/".
Regards,
Graham
--
-
[EMAIL PROTECTED]   "There's a moon
over Bourbon Street
tonight..."

Re: httpd 1.3 running processes mem usage

[Aaron Bannert]

On Wednesday, August 6, 2003, at 10:33  AM, Austin Gonyou wrote:

If I have a Linux server using httpd 1.3 and has 1GB ram and has 1012
httpd processes. When I look at that process's ram stats, I have a
vmSize of say 7032KB, vmRSS of 2056KB, and  vmEXE of 2072KB.
Is the size I'm most concerned with when looking at per/process memory
utilization going to be vmSize? We're trying to tune our servers a bit
better until we're ready to move to httpd2, which will sometime at the
beginning of 2004. But help around this diagnosis would be appreciated.
This is one of the main features of httpd-2.0's worker MPM. That is,
significantly reduced memory usage. It is likely that when you switch
to 2.0 you'll see an order of magnitude reduction is memory usage for
the same number of concurrent requests.
-aaron

Re: cvs commit: httpd-2.0/modules/mappers mod_rewrite.c

[Thom May]

* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote :
> nd  2003/08/05 10:44:02
> 
>   +return "RewriteLog and RewriteLogLevel are not support by this build "
supported

Cheers
-Thom

Re: ap_run_sub_req problem

[William A. Rowe, Jr.]

Aryeh, please take a look at mod_negotiation for an example of where we
look at several subrequests, choose a best-match based on mime headers,
and then promote that subrequest to become the real request.

Bill

At 09:22 AM 8/8/2003, Aryeh Katz wrote:
>Bill,
>I was wondering if the following in the filter documentation is a doc bug based 
>on your comments below:
>
>"The second case for sub-requests is when one sub-request is going to 
>become the real request. This happens whenever a sub-request is created 
>outside of a handler or filter, and NULL is passed as the next filter to the 
>make_sub_request function."
>
>This seems to imply that it is possible to pass a NULL for the filter, and still 
>have it become the real request (which I assume is done in a method similar 
>to run_sub_req).
>Can you shed some light on this please?
>Thanks.
>Aryeh
>
>
>> The NULL argument for the filter is *ONLY* to be used for testing
>> subrequests that are not actually run to the client.  E.g.
>> mod_autoindex uses the NULL arg to consider what files might be
>> served, and if they are, in fact, actually valid content files, or if
>> they have been protected or otherwise cannot be handled.
>> 
>> You must pass the appropriate filter arg in order to pass the response
>> through the filter stack back to the client.
>> 
>> Look, instead, at mod_include.c or another module that actually serves
>> the subrequest, for an example of the appropriate way to use this API.
>> 
>> Bill
>> 
>> At 02:37 PM 8/6/2003, Aryeh Katz wrote:
>> >In certain circumstances, I need to do an internal redirect on the
>> >client's request (without sending back a redirect to the client). I
>> >tried using ap_sub_req_method_uri (specifying NULL for the filter),
>> >and then ap_run_sub_req. I see that the content type of the new
>> >request is correct (in my case, image/gif). However, when the request
>> >is sent to the client, the content type is text/plain. Thus, the
>> >reply to the client doesn't render properly. I suspect I am not
>> >invoking ap_run_sub_req properly. Is there something I should know
>> >about how to invoke run_sub_req? Thanks. Aryeh
>> >
>> >---
>> >Aryeh Katz
>> >Secured-Services Inc.
>> 
>
>
>---
>Aryeh Katz
>Secured-Services Inc.

Re: httpd 1.3 running processes mem usage

[Austin Gonyou]

Thanks so much. We've got much less confusion about this now. Good link,
btw. 

On Wed, 2003-08-06 at 13:07, Justin Erenkrantz wrote:
[...]
> Linux uses optimistic memory allocation.  Therefore, vmSize will be
> what has 
> been asked for, but may not be allocated (or is swapped to disk). 
> vmEXE will 
> most likely be shared across all of the httpd processes (copy on
> write).
> 
> I'd be most concerned about vmRSS which is the resident memory size -
> it is 
> how much is in physical memory.
> 
> "I Feel Lucky" on "RSS memory size" yields:
> 
> 
> 
> That has a bit more information.  -- justin
-- 
Austin Gonyou <[EMAIL PROTECTED]>
Coremetrics, Inc.

Re: ap_run_sub_req problem

[William A. Rowe, Jr.]

The NULL argument for the filter is *ONLY* to be used for testing subrequests
that are not actually run to the client.  E.g. mod_autoindex uses the NULL arg
to consider what files might be served, and if they are, in fact, actually valid
content files, or if they have been protected or otherwise cannot be handled.

You must pass the appropriate filter arg in order to pass the response through
the filter stack back to the client.

Look, instead, at mod_include.c or another module that actually serves the
subrequest, for an example of the appropriate way to use this API.

Bill

At 02:37 PM 8/6/2003, Aryeh Katz wrote:
>In certain circumstances, I need to do an internal redirect on the client's 
>request (without sending back a redirect to the client).
>I tried using ap_sub_req_method_uri (specifying NULL for the filter), and then 
>ap_run_sub_req.
>I see that the content type of the new request is correct (in my case, 
>image/gif). However, when the request is sent to the client, the content type 
>is text/plain. Thus, the reply to the client doesn't render properly.
>I suspect I am not invoking ap_run_sub_req properly.
>Is there something I should know about how to invoke run_sub_req?
>Thanks.
>Aryeh
>
>---
>Aryeh Katz
>Secured-Services Inc.

apache 2.0.46 mastercard patch :) (fwd)

[Rich Bowen]

I was speaking with someone today on IRC who is experiencing a problem
with QUERY_STRING in Apache 2.0. If I correctly understand the
situation, QUERY_STRING getting sent as an empty string, rather than the
old behavior of just not setting it at all, is causing a strange
interaction with CGI.pm.

More explanation and a patch follows. I wondered if it might not be
better to just undef it, but I guess I'm not clear why this change was
made in the first place. Can someone elaborate on this for me?

Oh, and, ps, MasterCard loves Apache, and is ditching iPlanet in favor
of Apache. :-)

-- 
Rich Bowen - [EMAIL PROTECTED]
Apache Cookbook - http://www.oreilly.com/catalog/apacheckbk/

-- Forwarded message --
Date: Mon, 11 Aug 2003 13:04:35 -0500
From: Sarah NameWithheldToProtectTheInnocent
To: [EMAIL PROTECTED]
Subject: apache 2.0.46 mastercard patch :)

file: util_script.c
line: 370
old line: apr_table_setn(e, "QUERY_STRING", r->args ? r->args : "");
new line: apr_table_setn(e, "QUERY_STRING", r->args ? r->args : " ");

Instead of undefing the parameter and dealing with all the possible
consequences of that, we redefined it as a space which seemed to
eliminate the quirky interaction with CGI.pm.  And, again the quirky
behavior appears in the sample code below when the param bug is
defined.

bash-2.03$ diff util_script.c mc_util_script.c
370c370
< apr_table_setn(e, "QUERY_STRING", r->args ? r->args : " ");
---
> apr_table_setn(e, "QUERY_STRING", r->args ? r->args : "");


#! /sys_apps_01/webadmin/bin/perl -T
# apache bug fun

use CGI;
$cgi = new CGI;

print $cgi->header();
print "Normal 1:";
showData($cgi);

if ($cgi->param("bug")) {
   $cgi2 = new CGI();
   print "Bug!!!";
}

$cgi = new CGI;

print "Normal 2:";
showData($cgi);

print "Done";
exit;

sub showData {
   my($cgi) = @_;

   foreach ($cgi->param()) {
  print "   $_ = " . $cgi->param("$_") . "";
   }
}

[patch-2.1] DECLINE_CMD and ITERATE

[Geoffrey Young]

hi all...

  currently, using DECLINE_CMD to override config directives has a 
limitation - you can't override ITERATE or ITERATE2 prototypes properly. 
what ends up happening is that DECLINE_CMD is returned for the first 
argument, but then Apache skips over your module for all subsequent 
arguments.  the only way around this (that I was able to figure out, that 
is) is to use RAW_ARGS when overriding these prototypes and do the parsing 
yourself.

  attached is a patch that fixes this, keeping ITERATE and ITERATE2 focused 
on the current module until the argument list is exhausted.

--Geoff
Index: server/config.c
===
RCS file: /home/cvspublic/httpd-2.0/server/config.c,v
retrieving revision 1.164
diff -u -r1.164 config.c
--- server/config.c 17 Feb 2003 07:04:50 -  1.164
+++ server/config.c 5 Aug 2003 19:26:59 -
@@ -697,7 +697,7 @@
   void *mconfig, const char *args)
 {
 char *w, *w2, *w3;
-const char *errmsg;
+const char *errmsg = NULL;
 
 if ((parms->override & cmd->req_override) == 0)
 return apr_pstrcat(parms->pool, cmd->name, " not allowed here", NULL);
@@ -797,11 +797,14 @@
 
 case ITERATE:
 while (*(w = ap_getword_conf(parms->pool, &args)) != '\0') {
-if ((errmsg = cmd->AP_TAKE1(parms, mconfig, w)))
+
+errmsg = cmd->AP_TAKE1(parms, mconfig, w);
+
+if (errmsg && strcmp(errmsg, DECLINE_CMD) != 0)
 return errmsg;
 }
 
-return NULL;
+return errmsg;
 
 case ITERATE2:
 w = ap_getword_conf(parms->pool, &args);
@@ -812,11 +815,14 @@
cmd->errmsg ? ", " : NULL, cmd->errmsg, NULL);
 
 while (*(w2 = ap_getword_conf(parms->pool, &args)) != '\0') {
-if ((errmsg = cmd->AP_TAKE2(parms, mconfig, w, w2)))
+
+errmsg = cmd->AP_TAKE2(parms, mconfig, w, w2);
+
+if (errmsg && strcmp(errmsg, DECLINE_CMD) != 0)
 return errmsg;
 }
 
-return NULL;
+return errmsg;
 
 case FLAG:
 w = ap_getword_conf(parms->pool, &args);

Re: mod_rewrite: different behaviour on sub-requests - Why?

[Cliff Woolley]

On Wed, 6 Aug 2003, André Malo wrote:

> The problem is, for example, that you cannot , since the subrequest won't be rewritten.
> (Sure, this affects .htaccess rules only, but a lot of people don't have the
> choice ...).

Ah.  Well, okay, +1 for 2.1 then.

Re: [PATCH] Trivial patch for C++ modules (2.0.47)

[William A. Rowe, Jr.]

At 10:44 PM 7/31/2003, Mahadevan R wrote:

>While trying to write an Apache2 module in C++, I found that in the command table, 
>AP_INIT_TAKE1 has to be used like this:
>
>AP_INIT_TAKE1( "Directive", (cmd_func) drctv_handler, NULL, OR_ALL, "help string")
>
>The compiler I'm using (MSVC++ 6.0) does not support "designated initializers". Hence
>the compiler expects the function drctv_handler to have a signature of
>"const char *(*cmd_func) ();" whereas it actually has a signature of
>"const char *(*take1) (cmd_parms *parms, void *mconfig, const char *w);".
>
>The situation can be easily solved (worked around?) by changing the definition of
>AP_INIT_TAKE1 (and its friends) in http_config.h to:
>
># define AP_INIT_TAKE1(directive, func, mconfig, where, help) \
>   { directive, (cmd_func) func, mconfig, where, TAKE1, help }

We have a very strong policy against casts at all costs when it will likely
mask a developers error.  I would be much more happy to consider a patch
that introduced specific prototypes for the TAKE1_fn, TAKE12_fn, etc
function type declarations.

Bill 

RE: cvs commit: httpd-2.0/modules/ssl ssl_engine_kernel.c

[Sander Striker]

> From: Jeff Trawick [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 08, 2003 11:17 AM

> Sander Striker wrote:
> 
> >>Hmm. You have a request_rec there. How about:
> >>
> >>   ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
> >> "Encountered FakeBasicAuth spoof: %s", username);
> >>
> >>Providing the request means that you get more information in the error_log.
> > 
> > 
> > Duh.  Thx,
> 
> Plz assume my +1 for APACHE_2_0_BRANCH is for the forthcoming rerror 
> version :)

*grin* Thanks Jeff.


Sander

Re: [Slightly OT] compiled source distribution question

[Mark W. Webb]

It appears that I may distribute only the parts of the compiled that I
so desire, as long as I retain all disclaimer/copyright info.


Cliff Woolley wrote:

  On Mon, 11 Aug 2003, Mark W. Webb wrote:

  
  
If I compile apache, and distribute the binaries, are there any
requirements on what I package in my application?  For instance, must I
distribute the manual files that get installed when I perform a "make
install" ?

  
  
The license tells you what the requirements are:

 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution,
 *if any, must include the following acknowledgment:
 *   "This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowledgment may appear in the software itself,
 *if and wherever such third-party acknowledgments normally appear.
 *
 * 4. The names "Apache" and "Apache Software Foundation" must
 *not be used to endorse or promote products derived from this
 *software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED].
 *
 * 5. Products derived from this software may not be called "Apache",
 *nor may "Apache" appear in their name, without prior written
 *permission of the Apache Software Foundation.

--Cliff
  





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Darwin and IPv6 was Re: cvs commit: httpd-2.0/server listen.c

[John K . Sterling]

On Thursday, August 14, 2003, at 01:06 PM, Colm MacCarthaigh,,, wrote:

.. or similar. The darwin one is complicated, but I know of at least
3 people running Apache on Darwin for months, all they've been doing
is changing v6_broken to 0 in the apr configure script ;)
Yup.. that worked.  make that 4 people :)

sterling

Re: About time to do 2.0.48?

[Brad Nicholes]

Cliff,
Do any of these funky bucket issues have anything to do with the
bucket_max_alloc() functionality that we have talked about in the past? 
It would really be nice to be able to control the bucket allocations.

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> [EMAIL PROTECTED] Friday, August 08, 2003 11:37:39 AM >>>
On Fri, 8 Aug 2003, Sander Striker wrote:

> I envision tagging somewhere next (mid) week, following
> release 1 or 2 weeks after that.

I'm starting to think it might be nice if we can push this back to say
Thursday instead of Tuesday-ish as was suggested last night... I
rally
want to wrap these (now three) funky bucket problems (Bojan's, Ron's,
and
Glenn's), and I just plain won't have time to work on them until
Monday.

--Cliff

Re: mod_ssl POST issue? (fwd)

[Kris Verbeeck]

Nope, it's still there.

Cliff Woolley wrote:
Anybody remember if we ever got around to implementing a workaound for the
POST method and per-directory renegotiations?
--Cliff

-- Forwarded message --
Date: Wed, 6 Aug 2003 18:59:05 -0500
From: john lawler <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: mod_ssl POST issue?
Hi Cliff,

I found the below quoted note on a messageboard.  This isn't still a bug in mod_ssl is it?  I'm encountering similar behavior using a php POST method.

Thanks,

jl
  a.. From: Cliff Woolley
  b.. Subject: Re: POST / SSL / Client Certificates Problem
  c.. Date: Mon, 08 Apr 2002 12:00:50 -0700
- 

On Sun, 7 Apr 2002 [EMAIL PROTECTED] wrote:


I'm using Apache 2 beta, mod_ssl (obviously), and a few self-signed
client certificates. My problem is that when I try to POST to a .cgi
file, I get the following error: "Method not allowed! The POST method is
not allowed for the requested URL."


This is a known issue with mod_ssl for Apache 2.0... it's on the
modules/ssl/TODO list.
Thanks,
Cliff


--
ir. Kris Verbeeck
Software Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T:  +32 16 28 70 64
F:  +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com

Re: httpd 1.3 running processes mem usage

[Justin Erenkrantz]

--On Wednesday, August 6, 2003 12:33 PM -0500 Austin Gonyou 
<[EMAIL PROTECTED]> wrote:

If I have a Linux server using httpd 1.3 and has 1GB ram and has 1012
httpd processes. When I look at that process's ram stats, I have a
vmSize of say 7032KB, vmRSS of 2056KB, and  vmEXE of 2072KB.
Is the size I'm most concerned with when looking at per/process memory
utilization going to be vmSize? We're trying to tune our servers a bit
better until we're ready to move to httpd2, which will sometime at the
beginning of 2004. But help around this diagnosis would be appreciated.
Linux uses optimistic memory allocation.  Therefore, vmSize will be what has 
been asked for, but may not be allocated (or is swapped to disk).  vmEXE will 
most likely be shared across all of the httpd processes (copy on write).

I'd be most concerned about vmRSS which is the resident memory size - it is 
how much is in physical memory.

"I Feel Lucky" on "RSS memory size" yields:



That has a bit more information.  -- justin

mod_include: YABU (yet another bug uncovered)

[Ron Park]

Hi Again,

Well, we've come across another mod_include/cross brigade bug for which we
currently don't yet have a patch (should have one soon but thought I'd give
others a crack at it). :D

Here are two simple snippets, one which works, one which causes a core
dump even with the latest patch of mod_include:

TrueSetFalseSetDone

TSetFalseSetDone

(The Cntl-P is to cause mod_bucketeer to fire off: need the following
setting in your conf file to get this to work:

AddOutputFilter BUCKETEER;INCLUDES .html

Put each snippet in a file in your docroot, say, true.html and t.html and give
them a try.

I'm pretty sure it's related to the code around line 491 of mod_include.c
(at least that's the part that works differently for each one) but I haven't
figured out how it's wrong.

Thanks,
Ron

Re: suexec+CGI = zombies in 1.3.28

[Jeff Trawick]

Ralf S. Engelschall wrote:
Index: alloc.c
===
RCS file: /e/apache/cvs/apache-1.3/src/main/alloc.c,v
retrieving revision 1.145
diff -u -d -r1.145 alloc.c
--- alloc.c 20 Jun 2003 15:05:40 -  1.145
+++ alloc.c 29 Jul 2003 19:07:46 -
@@ -2859,12 +2859,8 @@
if ((p->kill_how == kill_after_timeout)
|| (p->kill_how == kill_only_once)) {
/* Subprocess may be dead already.  Only need the timeout if not. */
-   if (ap_os_kill(p->pid, SIGTERM) == -1) {
-p->kill_how = kill_never;
-}
-else {
-   need_timeout = 1;
-}
+   ap_os_kill(p->pid, SIGTERM);
+   need_timeout = 1;
The drawback of this is that often* when suexec is not in use we end up 
burning extra syscalls when it is not necessary.

*"often" is speculation and not something I've tested

If it were instead:

if (ap_os_kill(p->pid, SIGTERM) == -1 &&
errno == ESRCH) {
p->kill_how = skip_timeout; /* some new value */
}
else {
need_timeout = 1;
}
we'd still do the waitpid() at the end but we wouldn't insert a needless 
timeout loop when we know this child is a goner.

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

[Justin Erenkrantz]

--On Wednesday, August 13, 2003 15:14:40 -0600 Brad Nicholes 
<[EMAIL PROTECTED]> wrote:

This change causes a problem on NetWare.  In the function
alloc_listener() before the change,  the code did not allow the variable
addr to be NULL.  In the changed code addr is allowed to be NULL which
means that the call to strcmp() after the call to
apr_sockaddr_port_get() causes NetWare to fault.
Hmm.  Now, I wonder how reliant we are upon the sockaddr_t having a 
non-NULL hostname field.  Are we going to be allowed to leave it NULL? 
apr_sockaddr_info_get's documentation explicitly says it allows NULL 
inputs, but it doesn't say what the 'hostname' field will turn into.

The IPv4 apr_sockaddr_info_get impl. just hardcodes sa->hostname to be 
"0.0.0.0", while the IPv6 branch (getaddrinfo impl) will leave it NULL. 
So, we may not reuse listeners on IPv4 right now (NULL gets translated into 
"0.0.0.0" and stored as that string in the sockaddr_t).  I guess I'll 
prefer to have the hostname be what we passed into apr_sockaddr_info_get - 
that is the sa->hostname should be NULL even with IPv4 implementations.

Then, we'll have to fix up the references to sa->hostname to allow for NULL 
values.

Thoughts?  Make sense?  -- justin

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

[Brad Nicholes]

  Right, so default to "::" for IPV6.  Either way, these two versions of
find_addresses() should be sync'ed up.

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> [EMAIL PROTECTED] Wednesday, August 13, 2003 5:00:21 PM >>>
--On Wednesday, August 13, 2003 16:57:34 -0600 Brad Nicholes 
<[EMAIL PROTECTED]> wrote:

> in the non-getaddrinfo() implementation).  It seems that both
> implementations should be sync'ed up to produce the same results. 
It
> appears that defaulting to "0.0.0.0" rather than NULL would be the
safer
> thing to do.

But, that's an IPv4 address, but we support IPv6.

Apparently, this series of commits broke Linux.  I bet this is where
Joe's 
ADDRCONFIG patch comes into play.  Looking into it now.  -- justin

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

[Justin Erenkrantz]

--On Wednesday, August 13, 2003 17:08:40 -0600 Brad Nicholes 
<[EMAIL PROTECTED]> wrote:

  Right, so default to "::" for IPV6.  Either way, these two versions of
find_addresses() should be sync'ed up.
I just committed fixes to sync up the other way (NULL returns) and added 
back the 'retry' logic if we have IPv6-enabled, but not configured (but in 
a different way than before).

Please let me know how that works.  It works on Linux, and I'll test 
Solaris again.  -- justin

Re: Darwin and IPv6 was Re: cvs commit: httpd-2.0/server listen.c

[Justin Erenkrantz]

--On Thursday, August 14, 2003 6:06 PM +0100 "Colm MacCarthaigh,,," 
<[EMAIL PROTECTED]> wrote:

Both these things really need to happen. The first is relatively
trivial:
Yup, I agree.  I committed a variant of this to the tree.  (The patch you 
submitted would only execute if the APR_IPV4_ADDR_ONLY flag or whatever would 
be passed in.)

Until a truly AF agnostic ACL implementation can be used (see
http://www.stdlib.net/~colmmacc/nsd/subnet.h and the accomponying
subnet.c for a rough idea) the Darwin problem should be solveable
by checking the IN6_IS_ADDR_V4MAPPED macro, and if so ignoring
the first 96 bytes and passing the last 32 on.
Hmm.  Would it be possible to submit a patch for this?  I'm not entirely clear 
where this would go.

This is the bug I was trying to get across (badly) the day before
yesterday. The fact that getaddrinfo returns a linked list is pretty
much ignored by alloc_listener :(
Okay, let me take a pass at trying to fix this.  I think this should be 
solvable pretty easily.

http://www.apache.org/~jerenkrantz/getaddr.c
That has a a bug of it's own :)
Thanks.  Fixed.  ;-)  -- justin

Darwin and IPv6 was Re: cvs commit: httpd-2.0/server listen.c

[Justin Erenkrantz]

--On Thursday, August 14, 2003 7:56 AM -0400 "John K. Sterling" 
<[EMAIL PROTECTED]> wrote:

I'm still having problems with HEAD this morning on os X (Darwin Kernel
Version 6.6) - is that expected?  (i'm not sure what the status is, but the
above email implies a fix was applied).
(22)Invalid argument: make_sock: could not bind to address :80
no listening sockets available, shutting down
No, it's not expected.  ;-)

But, here's what the problem is:

- We've disabled IPv6 across the board on Darwin because getnameinfo() doesn't 
do IPv6->IPv4 mapping correctly (my rough probably incorrect remembrance of 
the thread).  The thread in question was from last October:



- We're getting IPv6 addresses back from getaddrinfo() because, well, that's 
what getaddrinfo is supposed to return.  The IPv6 addresses are returned back 
to alloc_listener.

- APR_HAVE_IPV6 is 0, so the apr_sockaddr_t doesn't contain the sin6 field in 
the union.

- You'll notice that the 22 is EINVAL (*not* EHOSTUNREACH).  That's because 
the sockaddr_in6 that we copied from getaddrinfo's return list is corrupted.

So, a few suggestions:

- Trim IPv6 addresses from getaddrinfo()'s return values if APR_HAVE_IPV6 is 0.
 (Perhaps only allow PF_INET sockets values to go in there.)
- Re-enable IPv6 on Darwin, and try to come up with a better solution to the 
problem proposed last October.  (I proposed this before, but no one was 
interested.)

And, I'm not sure if this is expected or not, but binding to the IPv6 address 
on my Darwin box does *not* bind to the IPv4 interface.  In order to do that, 
we'd have to bind to each address returned from getaddrinfo().  But, we'll 
only bind to the first one.  I think that's wrong.  Or, perhaps binding to the 
IPv6 interface is supposed to bind to the IPv4 interface, but my tests on 
Darwin don't show that to hold.  Try out:

http://www.apache.org/~jerenkrantz/getaddr.c

This IPv6 code is just a complete mess.  -- justin

Cleaning old releases from dist/httpd/

[Joshua Slive]

In the past, we have kept old releases on www.apache.org/dist/httpd/
essentially indefinitely by moving them into "old/" directories.  This is
no longer a good idea for at least couple reasons:

1. Now that www.apache.org/dist/ contains (or will soon contain) all
ASF releases, it is unreasonable to ask our mirrors to provide disk space
for both current and past releases.  A policy of leaving all releases on
the mirrors would require many many gigabytes of disk space on every
mirror.

2. Moving things from one directory to another in the release directory
causes all the mirrors to need to resync, thereby wasting bandwidth.

The new policy for releases is now at:
http://www.apache.org/dev/mirrors.html

To impliment this policy, I will soon be going through the dist/httpd/
directory and removing all old/ directories and similar things.  Please
speak now if you have any objections to this.  All of these old releases
will remain permanently at http://archive.apache.org/dist/httpd/.  The
archive site maintains an automatic copy of the main dist/httpd/ site, but
it never deletes anything.  Therefore, in the future, you need only place
releases in the regular location, and delete them again after they are not
current.

Two quick related requests:

- We could still use a couple more regular backups of archive.apache.org.
Something like
rsync -rtlzv --delete archive.apache.org::archive-site
will do the trick if placed in a daily cron.  Please let me know if you
can do this.

- If anyone has older releases of apache httpd (pre 1.2.6), now would be a
great time to make them public again by dropping them into the archive
site at
minotaur.apache.org:/www/archive.apache.org/dist/httpd

Thanks.

Joshua.

Re: File buckets v. core_output_filter

[Bojan Smojver]

You can give this a go. Maybe it's something I'm doing in there that is
causing the problem, not sure.

Anyway, you'll notice commented flush buckets. When you turn them on,
the output should start making sense.

I'm also attaching the test file.

On Thu, 2003-08-07 at 23:06, Cliff Woolley wrote:

> I'll try to construct a test for that case and see what's going on in core
> output.  Hey Greg... seen anything like this?

-- 
Bojan
/**
 * mod_testfilebucket.c
 *
 * This software is licensed under GNU General Public License
 * http://www.gnu.org/copyleft/gpl.html
 *
 * Bojan Smojver, Rexursive, 2003
 *
 */

#include "apr.h"
#include "apr_strings.h"
#include "apr_lib.h"
#include "apr_hash.h"
#include "apr_optional.h"

#define APR_WANT_STRFUNC
#include "apr_want.h"

#include "ap_config.h"
#include "util_filter.h"
#include "httpd.h"
#include "http_core.h"
#include "http_config.h"
#include "http_log.h"

module AP_MODULE_DECLARE_DATA testfilebucket_module;

#define TEST_MAGIC_TYPE "httpd/testfilebucket"

/*
 * The handlers...
 */

static int testfilebucket_handler(request_rec *r){
  conn_rec *c=r->connection;
  apr_bucket_brigade *bb;
  apr_bucket *b;
  apr_file_t *fp;
  char *buffer;

  if(strcmp(r->handler,TEST_MAGIC_TYPE) && strcmp(r->handler,"testfilebucket"))
return DECLINED;

  buffer=apr_pstrdup(r->pool,"SOME TEXT\n");

  bb=apr_brigade_create(r->pool,c->bucket_alloc);

  apr_file_open(&fp,r->filename,APR_READ,APR_OS_DEFAULT,r->pool);

  b=apr_bucket_file_create(fp,0,3200,r->pool,c->bucket_alloc);
  APR_BRIGADE_INSERT_TAIL(bb,b);

//  b=apr_bucket_flush_create(c->bucket_alloc);
//  APR_BRIGADE_INSERT_TAIL(bb,b);

  b=apr_bucket_pool_create(buffer,10,r->pool,c->bucket_alloc);
  APR_BRIGADE_INSERT_TAIL(bb,b);

  b=apr_bucket_file_create(fp,3210,80,r->pool,c->bucket_alloc);
  APR_BRIGADE_INSERT_TAIL(bb,b);

//  b=apr_bucket_flush_create(c->bucket_alloc);
//  APR_BRIGADE_INSERT_TAIL(bb,b);

  b=apr_bucket_pool_create(buffer,10,r->pool,c->bucket_alloc);
  APR_BRIGADE_INSERT_TAIL(bb,b);

  b=apr_bucket_file_create(fp,3300,3200,r->pool,c->bucket_alloc);
  APR_BRIGADE_INSERT_TAIL(bb,b);

//  b=apr_bucket_flush_create(c->bucket_alloc);
//  APR_BRIGADE_INSERT_TAIL(bb,b);

  ap_pass_brigade(r->output_filters,bb);

  return OK;
}

/*
 * The hooks...
 */

static void register_hooks(apr_pool_t *p){
  ap_hook_handler(testfilebucket_handler,NULL,NULL,APR_HOOK_MIDDLE);
}

module AP_MODULE_DECLARE_DATA testfilebucket_module={
  STANDARD20_MODULE_STUFF,
  NULL,   /* create per-dir config */
  NULL,   /* merge per-dir config */
  NULL,   /* server config */
  NULL,   /* merge server config */
  NULL,   /* command apr_table_t */
  register_hooks  /* register hooks */
};
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234567890123456789012345678901234567890123456789012345678
0123456789012345678901234