Re: Configure for 1.3.21 is semi-"broken"

[Greg Stein]

On Thu, Oct 04, 2001 at 11:37:55AM -0400, Jim Jagielski wrote:
> Just saw this in Configure after Cliff's note (which is resolved):
>...
> Note the line above the ''. Luckily, this section still works
> as required (lucky typo)... But there's a mismatch of logic here, regarding
> what the EXPAT rule really means... Right now, if there's a system
> expat lib, it will *always* be chosen, and there's no way to bypass
> that. Up to now, I think we've always been using expat-lite... Because

The *intent* is to always choose the system Expat over our bundled version.
This also happens to be the same behavior that we now have in apr-util.

RULE_EXPAT in Apache 1.3 means "give me Expat". Doesn't matter *where* it
comes from, as long as it is available in the process.

Point being that we want to use the system's .so when possible, so that
other things in the Apache process which need Expat will link against the
*same* .so.

In the current world, if Apache brings Expat symbols into the process, and
something down the line also brings in Expat (because it doesn't know Expat
has already been loaded), then we get all kinds of problems. The specific
scenario is that mod_perl runs a Perl script which loads the standard
XML::Parsers::Expat module; that module knows *nothing* about Apache. All it
can know about is the system Expat.

Apache has no need to provide its own, so choosing the system version is
always preferable. Since the Expat API is way stable, this works quite fine.

>...
> Sorry I didn't notice this sooner... After the dust settles I'll
> adjust this section to deal with the new logic.

Um... *why* would you want to disable the use of the system version in favor
of the builtin one? I don't see and can't imagine a use case for that.
(which is why I coded the selection this way)

Cheers,
-g

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

Re: [PATCH] some fixes for ap_http_filter

[Roy T. Fielding]

On Thu, Oct 04, 2001 at 07:50:33PM -0700, Justin Erenkrantz wrote:
> On Thu, Oct 04, 2001 at 07:13:16PM -0700, Aaron Bannert wrote:
> > Huh? That's a bit of a stretch. If this is going to turn into a style
> > war, let it be spoken from the Apache Style Guide:
> > 
> > "Opening braces are given on the same lines as statements, or on the
> > following line at the start of a function definition."
> 
> I'd like to point out the other bazillion places where this happens.
> I don't care.  I'm just pointing out that if you want to change
> the style, change style without changing anything else.  That
> seems to be the operative rule that most people work under.
> 
> Furthermore, I won't commit any patches that change the braces, so 
> there!  =)  When you finally get commit access or find someone who 
> agrees to enforce this point (I'm sure Ryan will do so), I don't 
> care.  It isn't a big enough of a deal.  *I DON'T CARE*  =)  
> Whatever...
> 
> [ Please realize that I'm writing this laughing... ]

You know, this type of bantering gets really annoying when it is on a mailing
list, even though it is pretty amusing to see you two discuss it over dinner.
Let's restrict the discussion to things you actually care about.

> > > No, I think that if you are not familiar that the C construct 
> > > (ctx->remaining) is equivalent to (ctx->remaining != 0) than I
> > > don't really have any sympathy for you.  IMHO, we're not here to 
> > > teach people C.  =)
> > 
> > Bzzzt, wrong! Those are not semantically equivalent statments. The !
> > operator treats the operand as a boolean, the == operator treats the
> > operands as the same type. Let me do some english translations:
> > 
> > if (!ctx->remaining) {
> > 
> >  "If ctx->remaining is not true..."
> > 
> > 
> > if (ctx->remaining <= 0) {
> > 
> >  "If ctx->remaining is less than or equal to zero..."
> > 
> > There is a huge semantic difference there, and it plays directly into the
> > readability of the code.
> 
> Yoohoo, look again - that's not what I said.  =)  I'm not disagreeing 
> that <= 0 is different (of course it is).  I'm saying that != 0 is 
> identical to not having the explicit comparison (and I bet there is
> someone out there that will prove me wrong).  Also, there is no 
> boolean type in C.  =)  You *are* thinking of Java - I knew it...

Aaron's change is correct -- it is one of the principles of defensive
programming that all logical branches of a program should be correctly
followed even if the input is unexpected.  Let's say a cosmic ray happens
to pass through the memory chip and sets that value to be negative.
Which branch of the tree is more likely to be a safe path?  An assert
is never a safe path in production code.

Likewise, defensive programming calls for curly-braces around blocks
of conditional code.  Don't argue about things that aren't worth the
effort of *me* having to read the argument.

Roy

Re: [PATCH] some fixes for ap_http_filter

[Greg Stein]

On Thu, Oct 04, 2001 at 10:01:37PM -0700, Justin Erenkrantz wrote:
>...
> On Thu, Oct 04, 2001 at 09:37:51PM -0700, Ian Holsman wrote:
> > how about we back out the filter changes so that the rest of the
> > server isn't broken.
> 
> I'd rather not see us back this change out.  But, it is your
> prerogrative to veto it.  I believe we need to chase this
> problem down and fix all of the filters.

Agreed. We have taken a large step forwards. Very large, thanks to Justin. I
identified these problems back in April or so, but never got the time to
carry them through (I started to make some changes once, but for various
reasons a good chunk was backed out). Thankfully, Justin found the time and
inclination.

To back these out now would just return us to the broken state we were in
before. Things *happened* to work because we'd hacked stuff up enough to
make it work. But the code was *wrong*.

Why should we revert to something that we know is wrong?

If we want mod_ssl or mod_proxy to work, then we can fix them. They *are*
broken, if they have made improper assumptions. But breaking the core to
solve their problems is not the right answer.

Backing it out and waiting for a complete patch isn't possible either. That
would be a huge and complex patch. It would not be reviewable, so we'd just
end up applying it without any real review. And hoping for the best...

With Justin's patch, we were able to review it, verify that it was a proper
step forward, and get it checked in. There were a couple additional patches
that he made, based on that review (suggestions from Ryan and myself). The
*next* step is to complete the propagation of fixes throughout the code
base.

>...
> Basically, these changes can only go as fast as the people 
> helping out.  And, there's only one of me.  =)  -- justin

Well said.

I can happily contribute knowledge, but am so backed up on various projects
that helping with coding just falls further and further behind. (sigh)

Cheers,
-g

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

Re: [PATCH] mod_ssl input filtering...

[Greg Stein]

On Thu, Oct 04, 2001 at 08:12:42PM -0700, Justin Erenkrantz wrote:
> On Thu, Oct 04, 2001 at 09:09:46PM -0400, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) 
>wrote:
>...
> > 'not necessarily. The renegotiation request can come from the
> > ssl_hook_Access() also - in which case ssl_hook_process_connection has no
> > business whatsoever..
> 
> What is the deal if renegotiation is set?  It doesn't do anything
> of interest, does it?  Why can't OpenSSL handle this transparently?

To renegotiate, OpenSSL must send data to the client. Since OpenSSL doesn't
have a socket, it needs the help of mod_ssl to deliver stuff to the client.
That is why the input/output filters are tied together -- you try to read,
need to renegotiate, send data to the client, read the result.

[ caveat: this is only based on something that I recall Ben saying once ]

>...
> > I'm a novice here and 'obviously missing something - can somebody tell me
> > why should a application not be given whatever it's asking for - especially
> > if it's geniune (think SSL) ?..  Also, I guess there has to be a
> > differentiator b/w a protocol and a application here.. A protocol should to
> > be given all the data it asks for (and in the format it asks for) - the

Nope. It asks for X and we'll give it *up to* X. If the app doesn't get the
full X, yet it wants more, then it can always call again for more data. This
is standard behavior for non-blocking systems (e.g. sockets and pipes).

>...
> I believe we have to read from the core in determinately-sized 
> chunks.  I don't think we can just say, "Give me everything."

Absolutely. The -1 mode can kind of do that, but it is so far beyond bogus
that we should not be building mod_ssl that way :-)  Therefore, you have to
have some kind of buffer size for reading from the next filter.

Cheers,
-g

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

Re: [PATCH] mod_ssl input filtering...

[Justin Erenkrantz]

On Thu, Oct 04, 2001 at 10:30:08PM -0700, Greg Stein wrote:
> *tempread ?? You might want to assign something to tempread first :-)

Yeah, I caught that one already.  =)

> >...
> > +pos = memchr(str, APR_ASCII_LF, len);
> 
> How about a new brigade function first?

Okay

> I don't know much about the rest of how this filter works, but I am
> seriously suspicious of the removal of the renegotiation code.

Madhu mentioned this too.  Where is the renegotiation code?  I'm
not seeing what you guys are talking about.  -- justin

P.S. Vainly trying to set up a build here locally so I don't have
to fight the network...

Re: [PATCH] mod_ssl input filtering...

[Greg Stein]

On Thu, Oct 04, 2001 at 01:03:32PM -0700, Justin Erenkrantz wrote:
>...
> --- modules/ssl/ssl_engine_io.c   2001/10/04 17:50:39 1.37
> +++ modules/ssl/ssl_engine_io.c   2001/10/04 19:54:22
>...
>  static apr_status_t ssl_io_filter_Input(ap_filter_t *f,
>  apr_bucket_brigade *pbbOut,
> -ap_input_mode_t eMode,
> +ap_input_mode_t mode,
>  apr_off_t *readbytes)
>  {
>  apr_status_t ret;
> -SSLFilterRec *pRec = f->ctx;
> +SSLFilterRec *ctx = f->ctx;
> +apr_status_t rv;
> +apr_bucket *e;
> +apr_off_t *tempread;
>  
> -/* XXX: we don't currently support peek */
> -if (eMode == AP_MODE_PEEK) {
> +/* XXX: we don't currently support peek or readbytes == -1 */
> +if (mode == AP_MODE_PEEK || *readbytes == -1) {
>  return APR_ENOTIMPL;
>  }
> +
> +/* Return the requested amount or less. */
> +if (*readbytes)
> +{
> +/* churn the state machine */
> +ret = churn_input(ctx, mode, readbytes);
> +
> +if (ret != APR_SUCCESS)
> + return ret;
> +
> +APR_BRIGADE_CONCAT(pbbOut, ctx->b);
> +return APR_SUCCESS;
> +}
> +   
> +/* Readbytes == 0 implies we only want a LF line. 
> + * 1024 seems like a good number for now. */
> +*tempread = 1024;

*tempread ?? You might want to assign something to tempread first :-)

>...
> +pos = memchr(str, APR_ASCII_LF, len);

How about a new brigade function first?


I don't know much about the rest of how this filter works, but I am
seriously suspicious of the removal of the renegotiation code.

Cheers,
-g

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

Re: [PATCH] some fixes for ap_http_filter

[Justin Erenkrantz]

[ Not sure if this is going to be sent twice - UCI's network 
  connection has decided to go bonkers tonight - I'm having 
  horrendous packet loss problems.  ]

On Thu, Oct 04, 2001 at 09:37:51PM -0700, Ian Holsman wrote:
> how about we back out the filter changes so that the rest of the
> server isn't broken.

I'd rather not see us back this change out.  But, it is your
prerogrative to veto it.  I believe we need to chase this
problem down and fix all of the filters.

I would highly recommend reading Greg's and Roy's emails about
the filtering change and their reasons why we shouldn't back 
this out.

They have spoken much more eloquently than I on this.  And,
they are probably much more respected than I ever will be.  =)  

Basically, these changes can only go as fast as the people 
helping out.  And, there's only one of me.  =)  -- justin

Re: cvs commit: httpd-2.0 Makefile.in

[William A. Rowe, Jr.]

From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Thursday, October 04, 2001 10:47 PM


> On Thu, Oct 04, 2001 at 10:40:20PM -0500, William A. Rowe, Jr. wrote:
> > >   Make sure we run the new conf files through sed.
> > >   Now, the question is whether it might make more sense to have them
> > >   as ssl-std.conf, ldap-std.conf, and proxy-std.conf.
> > >   
> > >   (I'm also not sure if this is even shell portable or not.)
> > >   
> > >   I'll leave that up to OtherBill since he added these files.
> > 
> > As the input source?  Sure.  I'll rename in just a bit if you want
> > to twiddle the script.
> 
> Actually, it'd copy it as ssl-std.conf.  I dunno if that is what
> we want or not.  Do we want them to have an original like 
> httpd-std.conf?  

On Win32 we cache the httpd.default.conf version (already substituted)
so the admin can go back to a known good point.  I won't waste the
effort copying a virgin file, just rewrite it to default.conf and then 
dup it to .conf.

Re: [PATCH] some fixes for ap_http_filter

[Ian Holsman]

Justin Erenkrantz wrote:

> On Thu, Oct 04, 2001 at 01:53:53PM -0700, Ian Holsman wrote:
> 
>>I've been debugging the proxy problem with the input filters, and it also 
>>seems
>>to be screwing up in this function as well.
>>
>>The proxy calls this function with a NULL request in the input filter,
>>causing the pool-alloc to fail (invalid access)
>>
>>by the looks of it the 'request' variable in the input_filters stucture
>>is NULL all the way back in process_connection.
>>
>>I was wondering how this happens?
>>(BTW.. this stuff was working with the CVS of Sep-20, before the input 
>>filter changes
>>went in)
>>
> 
> Yeah, proxy has probably been bitten by the input filter changes as
> well - as Roy has mentioned before, almost all input filters are now
> in a broken state.  This really needs everyone's attention.  =)
> 
> To make matters somewhat worse, I'm going out of town this weekend 
> and mod_ssl still isn't done yet, so either:
> 
> - Someone else needs to step in and fix mod_proxy (++1!)
> - It's got to wait until I return - which will probably be the
>   middle of next week before I can get to it.
> 

how about we back out the filter changes so that the rest of the
server isn't broken.


> Hopefully, I can finish up mod_ssl tonight so that the mod_proxy
> people or someone else has yet more clues on how this is supposed
> to work.  -- justin
> 
> 

Re: [PATCH] mod_ssl input filtering...

[Justin Erenkrantz]

On Thu, Oct 04, 2001 at 09:09:46PM -0400, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) 
wrote:
> HTTP filters.. But, I have some concerns : 
> Some applications may legitimately ask for x bytes, some may ask for a upper
> limit of x bytes, and some other may want to have all the data in the
> channel (SSL).. 

I see what you mean now.  =)

Try asking for 1024 bytes when there aren't that many bytes.  =)

apr_brigade_partition blocks.

Yuck.  The core needs to handle non-blocking reads via non-blocking
socket reads.  Going to have to fix that... =) -- justin

Re: SSL configuration file [httpd-ssl.conf - new file to be added ]

[Justin Erenkrantz]

On Fri, Oct 05, 2001 at 12:22:21AM -0400, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) 
wrote:
> Hi,
>   Here's a stripped down version of httpd-ssl.conf. As you can see,
> I've just stripped down some comments - there's only one statement per
> config parameter, and I added the comment "See the mod_ssl manual for more
> details".
> Pl.letme know if it's okay.. If anybody still feels that there's too much of
> documentation, pl. fee free to prune it.. 

Has anyone attempted to contact Ralf to see if we can use the
original mod_ssl manual?  From what I can tell, it says, "All rights
reserved" on the manual on mod_ssl's website.  Was that transferred
to the ASF as well as the code?  -- justin

RE: SSL configuration file [httpd-ssl.conf - new file to be added]

[MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)]

Hi,
Here's a stripped down version of httpd-ssl.conf. As you can see,
I've just stripped down some comments - there's only one statement per
config parameter, and I added the comment "See the mod_ssl manual for more
details".
Pl.letme know if it's okay.. If anybody still feels that there's too much of
documentation, pl. fee free to prune it.. 

Thx
-Madhu



Listen @@Port@@
Listen 443
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl.crl

#   Pass Phrase Dialog:
#   Configure the pass phrase gathering process.
#   The filtering dialog program (`builtin' is a internal
#   terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog  builtin

#   Inter-Process Session Cache:
#   Configure the SSL Session Cache: First either `none'
#   or `dbm:/path/to/file' for the mechanism to use and
#   second the expiring timeout (in seconds).
#SSLSessionCachenone
#SSLSessionCacheshmht:logs/ssl_scache(512000)
#SSLSessionCacheshmcb:logs/ssl_scache(512000)
SSLSessionCache dbm:logs/ssl_scache
SSLSessionCacheTimeout  300

#   Semaphore:
#   Configure the path to the mutual explusion semaphore the
#   SSL engine uses internally for inter-process synchronization. 
SSLMutex  file:logs/ssl_mutex

#   Pseudo Random Number Generator (PRNG):
#   Configure one or more sources to seed the PRNG of the 
#   SSL library. See the mod_ssl User Manual for more details.
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random  512
#SSLRandomSeed connect file:/dev/random  512

#   Logging:
#   The home of the dedicated SSL protocol logfile. Errors are
#   additionally duplicated in the general error log file.
#   Log levels are : none, error, warn, info, trace, debug.
SSLLog  logs/ssl_engine_log
SSLLogLevel info


##
## SSL Virtual Host Context
##



#  General setup for the virtual host
DocumentRoot "@@ServerRoot@@/htdocs"
ServerName new.host.name
ServerAdmin [EMAIL PROTECTED]
ErrorLog logs/error_log
TransferLog logs/access_log

#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on

#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

#   Server Certificate:
#   Point SSLCertificateFile at a PEM encoded certificate. Keep
#   in mind that if you've both a RSA and a DSA certificate you
#   can configure both in parallel.
SSLCertificateFile conf/ssl.crt/server.crt
#SSLCertificateFile conf/ssl.crt/server-dsa.crt

#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.
SSLCertificateKeyFile conf/ssl.key/server.key
#SSLCertificateKeyFile conf/ssl.key/server-dsa.key

#   Server Certificate Chain:
#   Point SSLCertificateChainFile at a file containing the
#   concatenation of PEM encoded CA certificates which form the
#   certificate chain for the server certificate.
#SSLCertificateChainFile conf/ssl.crt/ca.crt

#   Certificate Authority (CA):
#   Set the CA certificate verification path where to find CA
#   certificates for client authentication. The file must be
#   PEM encoded. See the mod_ssl documentation for more details.
SSLCACertificatePath conf/ssl.crt
#SSLCACertificateFile conf/ssl.crt/ca-bundle.crt

#   Certificate Revocation Lists (CRL):
#   Set the CA revocation path where to find CA CRLs for client
#   authentication. See the mod_ssl documentation for more details.
#SSLCARevocationPath conf/ssl.crl
#SSLCARevocationFile conf/ssl.crl/ca-bundle.crl

#   Client Authentication (Type):
#   Client certificate verification type and depth. Types are
#   none, optional, require and optional_no_ca. Depth is a
#   number which specifies how deeply to verify the certificate
#   issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth  10

#   Access Control:
#   With SSLRequire you can do per-directory access control based
#   on arbitrary complex boolean expressions containing server
#   variable checks and other lookup directives. See the mod_ssl
#   documentation for more details.
#
#SSLRequire (%{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \
#   and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
#   and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
#   and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20   ) \
#  or %{REMOTE_ADDR} =~ m/^190\.13\.190\.[0-9]+$/
#

#   SSL Engine Options:
#   Set various options for the SSL engine. Options are :
#FakeBasicAuth, ExportCertData, StdEnvVars, CompatEnvVars,
#StrictRequire, OptRenegotiate.
#   See the mod_ssl documentation for more details.
#SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire


SSLOptions +StdEnvVars


SSLOptions +StdEnvVars



#   SSL Protocol Adjustments:
#   When you need a different shutdown approach y

Re: cvs commit: httpd-2.0 Makefile.in

[Justin Erenkrantz]

On Thu, Oct 04, 2001 at 10:40:20PM -0500, William A. Rowe, Jr. wrote:
> >   Make sure we run the new conf files through sed.
> >   Now, the question is whether it might make more sense to have them
> >   as ssl-std.conf, ldap-std.conf, and proxy-std.conf.
> >   
> >   (I'm also not sure if this is even shell portable or not.)
> >   
> >   I'll leave that up to OtherBill since he added these files.
> 
> As the input source?  Sure.  I'll rename in just a bit if you want
> to twiddle the script.

Actually, it'd copy it as ssl-std.conf.  I dunno if that is what
we want or not.  Do we want them to have an original like 
httpd-std.conf?  

No biggie.  -- justin

Re: cvs commit: httpd-2.0 Makefile.in

[William A. Rowe, Jr.]

>   Make sure we run the new conf files through sed.
>   Now, the question is whether it might make more sense to have them
>   as ssl-std.conf, ldap-std.conf, and proxy-std.conf.
>   
>   (I'm also not sure if this is even shell portable or not.)
>   
>   I'll leave that up to OtherBill since he added these files.

As the input source?  Sure.  I'll rename in just a bit if you want
to twiddle the script.

Bill

Re: [PATCH] mod_ssl input filtering...

[Justin Erenkrantz]

On Thu, Oct 04, 2001 at 09:09:46PM -0400, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) 
wrote:
> I'm always of the opinion that bailing out is a correct way to go. It's
> possible that the ssl_io_hook_read be registered directly with (Open)SSL to
> perform the read/write operations - in which case, bailing out is a better
> alternative.. Whatever.. 

Well, I don't see how ssl_io_hook_read could read from the socket
anymore.  =)  So, that argument is kind of moot.  I really don't
like the fact that it sets errno - the caller (churn_input) never
checks errno or does anything with it.

I'd like to delay doing as much as I can with this function until
after the filter is working.  I'll revert NULL check in my tree.
We can deal with this function later...

> [snip]
> Any errors such as these will be handled by CORE_IN and it will 
> pass back the correct error code.  mod_ssl shouldn't do anything 
> here.  Remember, previously, it had to handle all of the socket 
> code - that is gone now.
> [snip]
> 
> Tell me if I'm missing something or my eyes are playing tricks here.. Except
> for the if (len == 0) loop, I don't see anything much that's missing from
> here.. If that's what you're referring, then fine.

Previously, the bucket that mod_ssl was reading from was the socket
bucket (which also had an indeterminate length).  We have now
changed the rules so that indeterminate length (i.e. -1) buckets
can't be passed outside of the core.  You should only assume
that you are getting bytes that were *already* read off the socket.
The EAGAIN/EOF/etc checks aren't really possible given that.  If
an EOF is returned, we'll never hit this code.

(Yes, this is sort of an implementation assumption - that we're
not getting the socket bucket back, but I think it is a fair one
to make.)

> This trick doesn't get you anything if you look at the code path.
> The renegotiation is handled by the process_connection hook.
> [snip]
> 
> 'not necessarily. The renegotiation request can come from the
> ssl_hook_Access() also - in which case ssl_hook_process_connection has no
> business whatsoever..

What is the deal if renegotiation is set?  It doesn't do anything
of interest, does it?  Why can't OpenSSL handle this transparently?
If renegotiating is occurring, then shouldn't there be 0 bytes to 
read?  What was there (i.e. set readbytes to 0 to "trick" 
http_filter) - doesn't make any sense to me.  If you can help me
understand, why we have to explicitly handle this, I'd like to 
be enlightened.

> I generally don't like the idea. It's really a *great* thing to have for
> HTTP filters.. But, I have some concerns : 
> Some applications may legitimately ask for x bytes, some may ask for a upper
> limit of x bytes, and some other may want to have all the data in the
> channel (SSL).. 

I don't believe that is correct - retreiving all of the bytes in the
channel (i.e. readbytes == -1) seems kind of bogus - it breaks all of
the abstractions and can easily cause a DoS (as Greg pointed out).

My understanding is that you are asking for x bytes.  You may get x 
bytes, or you may get  I'm a novice here and 'obviously missing something - can somebody tell me
> why should a application not be given whatever it's asking for - especially
> if it's geniune (think SSL) ?..  Also, I guess there has to be a
> differentiator b/w a protocol and a application here.. A protocol should to
> be given all the data it asks for (and in the format it asks for) - the
> interpretation of the data has to be minimal..
> It may so happen that a protocol is designed such that it first reads all
> the data available and then starts operating on it. I agree that it may be a
> bad design - but the requirements may be such - are we telling that such
> applications *cannot* work with Apache ?.. 

It can just read, but it has to read it in chunks that it determines.
A connection-based filter has the option of buffering the data that
it hasn't returned but has already processed.

> Also, consider the performance impact that this would have on the SSL
> transactions - take the case of a busy site where ssl data + certificates is
> of length 2k (some random size > 1024).. For each transaction, the
> SSL_accept is called atleast once more than the current model (because of
> the lack of data given to it)..  Taking into account how costly each SSL
> call can be, the new method would be introducing a substantial amount of
> delay. The SSL performance of Zeus webserver is something like 3x of Apache
> - every extra transaction in Apache matters. (I'm not trying to get into
> Zeus/Apache comparision here, but I'm just trying to see where Apache+SSL is
> heading towards).

I chose 1024 out of thin air, but that is also what ssl_io_hook_read
reads in one loop in the input filter (buf is 1024 characters).  If 
you have a suggestion on how to improve this number, I'm all ears.
I'd like to be able to avoid the pmemdup if at all possible.

I believe we have to read from the core in determin

Re: [PATCH] some fixes for ap_http_filter

[Justin Erenkrantz]

On Thu, Oct 04, 2001 at 07:13:16PM -0700, Aaron Bannert wrote:
> Huh? That's a bit of a stretch. If this is going to turn into a style
> war, let it be spoken from the Apache Style Guide:
> 
> "Opening braces are given on the same lines as statements, or on the
> following line at the start of a function definition."

I'd like to point out the other bazillion places where this happens.
I don't care.  I'm just pointing out that if you want to change
the style, change style without changing anything else.  That
seems to be the operative rule that most people work under.

Furthermore, I won't commit any patches that change the braces, so 
there!  =)  When you finally get commit access or find someone who 
agrees to enforce this point (I'm sure Ryan will do so), I don't 
care.  It isn't a big enough of a deal.  *I DON'T CARE*  =)  
Whatever...

[ Please realize that I'm writing this laughing... ]

> > As an aside, I'd rather not see any style changes be in the same
> > commit/patch as something that changes bytecode - unless enough
> > of the function is changed to warrant the rewrite.  I've been
> > told many times not to change style in a patch - and for the most 
> > part, I try not to do that anymore.  I'd just like to reinforce 
> > that behavior in others.  =)
> 
> My patch changes no visible functionality. Part of the patch simply added
> comments, almost *ALL* of it was to improve robustness and readability.
> Minor style changes definately fit into this.

I thought the comments were good.  I just didn't like the style 
changes.

> > No, I think that if you are not familiar that the C construct 
> > (ctx->remaining) is equivalent to (ctx->remaining != 0) than I
> > don't really have any sympathy for you.  IMHO, we're not here to 
> > teach people C.  =)
> 
> Bzzzt, wrong! Those are not semantically equivalent statments. The !
> operator treats the operand as a boolean, the == operator treats the
> operands as the same type. Let me do some english translations:
> 
> if (!ctx->remaining) {
> 
>  "If ctx->remaining is not true..."
> 
> 
> if (ctx->remaining <= 0) {
> 
>  "If ctx->remaining is less than or equal to zero..."
> 
> There is a huge semantic difference there, and it plays directly into the
> readability of the code.

Yoohoo, look again - that's not what I said.  =)  I'm not disagreeing 
that <= 0 is different (of course it is).  I'm saying that != 0 is 
identical to not having the explicit comparison (and I bet there is
someone out there that will prove me wrong).  Also, there is no 
boolean type in C.  =)  You *are* thinking of Java - I knew it...

I'm also saying that given the context < 0 is invalid and we should
fix it (as described below).

> > So, I think we should fix that problem (so that we can't read 
> > past the end of the body) - not hide it by checking for negative 
> > values.  So, I think we should check ctx->remaining < readbytes
> > before we call ap_get_brigade in ap_http_filter.  If ctx->remaining
> > is less than readbytes, only read in ctx->remaining.  How does
> > that sound?  -- justin
> 
> That would also be satisfactory. As long as we aren't making implicit
> assumptions on our input.

Right.  I think this is the way to go.  It makes sense and enforces
ctx->remaining to never be < 0 no matter what higher-level filters
request.  =)

At least we can agree on something.  =)  Mark this date down in 
history.  -- justin

Re: [PATCH] some fixes for ap_http_filter

[Aaron Bannert]

On Thu, Oct 04, 2001 at 06:51:33PM -0700, Justin Erenkrantz wrote:
> My comment about Aaron being a Java weenie is that he changed the
> brace to fit the recommended Java style.  At eBuilt, they wanted 
> us to place braces on the same line all the time - we had long
> discussions about this.  I refused.  =)  And, I think Aaron did 
> too at the time.  He's gone over to the darkside.  Nothing wrong 
> with that.

Huh? That's a bit of a stretch. If this is going to turn into a style
war, let it be spoken from the Apache Style Guide:

"Opening braces are given on the same lines as statements, or on the
following line at the start of a function definition."

> As an aside, I'd rather not see any style changes be in the same
> commit/patch as something that changes bytecode - unless enough
> of the function is changed to warrant the rewrite.  I've been
> told many times not to change style in a patch - and for the most 
> part, I try not to do that anymore.  I'd just like to reinforce 
> that behavior in others.  =)

My patch changes no visible functionality. Part of the patch simply added
comments, almost *ALL* of it was to improve robustness and readability.
Minor style changes definately fit into this.

Mixing major logical changes with style changes is a bad thing, and should
be avoided if not merely for the sake of the patch reviewer.

> > [To Justin]
> > 
> > Even if we were checking for zero/non-zero, I would want it to be
> > 
> > (ctx->remaining ==/!= 0)
> > 
> > We are not checking the boolean status of the variable, we are checking
> > the integer status. Shorthand does not equate to fewer instructions
> > and sometimes defeats readability.
> 
> No, I think that if you are not familiar that the C construct 
> (ctx->remaining) is equivalent to (ctx->remaining != 0) than I
> don't really have any sympathy for you.  IMHO, we're not here to 
> teach people C.  =)

Bzzzt, wrong! Those are not semantically equivalent statments. The !
operator treats the operand as a boolean, the == operator treats the
operands as the same type. Let me do some english translations:

if (!ctx->remaining) {

 "If ctx->remaining is not true..."


if (ctx->remaining <= 0) {

 "If ctx->remaining is less than or equal to zero..."

There is a huge semantic difference there, and it plays directly into the
readability of the code.

> I agree that it doesn't equate to any more or less bytecodes, but 
> it *does* equate to less typing for me - which is what I'm all 
> about now that my hands hurt so much.  

"bytecodes"? Now who's the java weenie? *grin* I think you meant
instructions.  Less typing is good, but so is more reading (beautiful
code gets more eyes in the OSS world, no?). :)

> As I said before, I think that if we have ctx->remaining < 0,
> then someone did something horribly wrong.  And, I think if
> someone didn't pay attention to r->remaining, it would be 
> possible to enter this state.  

I absolutely agree, but the problem stems from the fact that we are
trusting out input parameters to be valid. We can not guarantee that
other modules will behave, so why not be a little bit more conservative
in how we behave?

> So, I think we should fix that problem (so that we can't read 
> past the end of the body) - not hide it by checking for negative 
> values.  So, I think we should check ctx->remaining < readbytes
> before we call ap_get_brigade in ap_http_filter.  If ctx->remaining
> is less than readbytes, only read in ctx->remaining.  How does
> that sound?  -- justin

That would also be satisfactory. As long as we aren't making implicit
assumptions on our input.

-aaron

Re: [PATCH] some fixes for ap_http_filter

[Justin Erenkrantz]

On Thu, Oct 04, 2001 at 01:53:53PM -0700, Ian Holsman wrote:
> I've been debugging the proxy problem with the input filters, and it also 
> seems
> to be screwing up in this function as well.
> 
> The proxy calls this function with a NULL request in the input filter,
> causing the pool-alloc to fail (invalid access)
> 
> by the looks of it the 'request' variable in the input_filters stucture
> is NULL all the way back in process_connection.
> 
> I was wondering how this happens?
> (BTW.. this stuff was working with the CVS of Sep-20, before the input 
> filter changes
> went in)

Yeah, proxy has probably been bitten by the input filter changes as
well - as Roy has mentioned before, almost all input filters are now
in a broken state.  This really needs everyone's attention.  =)

To make matters somewhat worse, I'm going out of town this weekend 
and mod_ssl still isn't done yet, so either:

- Someone else needs to step in and fix mod_proxy (++1!)
- It's got to wait until I return - which will probably be the
  middle of next week before I can get to it.

Hopefully, I can finish up mod_ssl tonight so that the mod_proxy
people or someone else has yet more clues on how this is supposed
to work.  -- justin

Compiling Woes with Darwin (Apache 1.3.20)

[Joaquín Menchaca]

I was attempting to subscribe to appropriate list.  I apologize to the 
list in advanced in case this is not on the topic area/interest.  I am 
relatively new to Apache.  I have configured and compiled Apache before on 
HP-UX 10.20, Windows NT/2K, Solaris 7, DigitalUNIX, and naturally Linux.  
Now I am stuck on Mac OS X 10.1 trying to compile 1.3.20.

I get the following from stderr:

10,12d9
< cd ..; cc  -DDARWIN -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite 
-DNO_DL_NEEDED `./apaci` -o helpers/dummy helpers/dummy.c
< /usr/bin/ld: /usr/lib/libSystem.dylib load command 6 unknown cmd field
< make: *** [dummy] Error 1

I get the following from stdout:

Configuring for Apache, Version 1.3.20
  + Warning: Configuring Apache with default settings.
  + This is probably not what you really want.
  + Please read the README.configure and INSTALL files
  + first or at least run './configure --help' for
  + a compact summary of available options.
  + using installation path layout: Darwin (config.layout)
Creating Makefile
Creating Configuration.apaci in src
Creating Makefile in src
  + configured for Darwin platform
  + setting C compiler to cc
  + setting C pre-processor to cc -E -traditional-cpp
  + checking for system header files
  + adding selected modules
  + checking sizeof various data types
  + doing sanity check on compiler and options
** A test compilation with your Makefile configuration
** failed.  The below error output from the compilation
** test will give you an idea what is failing. Note that
** Apache requires an ANSI C Compiler, such as gcc.

 Error Output for sanity check 
= End of Error Report =

  Aborting!

---
Any suggestions?!?

  - Joaquin

Re: [PATCH] some fixes for ap_http_filter

[Justin Erenkrantz]

On Thu, Oct 04, 2001 at 01:53:12PM -0700, Aaron Bannert wrote:
> On Thu, Oct 04, 2001 at 01:29:26PM -0700, Ryan Bloom wrote:
> > > > -if (!ctx->remaining)
> > > > -{
> > > > +if (ctx->remaining <= 0) {
> > >
> > > No.  =)  Java weenie.
> > 
> > Huh?  How is this him being a Java weenie?  Aaron has changed a check
> > for !0 to a check for negative or 0.  Those two checks are not equivalent.
> > I'm not sure if this is a valid change or not yet, but I am wondering what the
> > comment is about.

My comment about Aaron being a Java weenie is that he changed the
brace to fit the recommended Java style.  At eBuilt, they wanted 
us to place braces on the same line all the time - we had long
discussions about this.  I refused.  =)  And, I think Aaron did 
too at the time.  He's gone over to the darkside.  Nothing wrong 
with that.

As an aside, I'd rather not see any style changes be in the same
commit/patch as something that changes bytecode - unless enough
of the function is changed to warrant the rewrite.  I've been
told many times not to change style in a patch - and for the most 
part, I try not to do that anymore.  I'd just like to reinforce 
that behavior in others.  =)

> [To Justin]
> 
> Even if we were checking for zero/non-zero, I would want it to be
> 
> (ctx->remaining ==/!= 0)
> 
> We are not checking the boolean status of the variable, we are checking
> the integer status. Shorthand does not equate to fewer instructions
> and sometimes defeats readability.

No, I think that if you are not familiar that the C construct 
(ctx->remaining) is equivalent to (ctx->remaining != 0) than I
don't really have any sympathy for you.  IMHO, we're not here to 
teach people C.  =)

I agree that it doesn't equate to any more or less bytecodes, but 
it *does* equate to less typing for me - which is what I'm all 
about now that my hands hurt so much.  

As I said before, I think that if we have ctx->remaining < 0,
then someone did something horribly wrong.  And, I think if
someone didn't pay attention to r->remaining, it would be 
possible to enter this state.  

So, I think we should fix that problem (so that we can't read 
past the end of the body) - not hide it by checking for negative 
values.  So, I think we should check ctx->remaining < readbytes
before we call ap_get_brigade in ap_http_filter.  If ctx->remaining
is less than readbytes, only read in ctx->remaining.  How does
that sound?  -- justin

RE: [PATCH] mod_ssl input filtering...

[MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)]

-Original Message-
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 04, 2001 4:51 PM
[snip]
> -if (ssl == NULL) {
> -return -1;
> -}
> -
> => Why is the checking not required ?.. If it's justified, then the
> corresponding check has to be eliminated from ssl_io_hook_write() also..

Yeah, it should be removed from ssl_io_hook_write as well.  But,
I wasn't changing that function.  =)  Checking for null on something
like this isn't our preferred style - if it is NULL, then something
really bad happened anyway.  (ssl can't be null under any normal
circumstances here if you see how the code is called - it just
doesn't add any value...)
[snip]


I'm always of the opinion that bailing out is a correct way to go. It's
possible that the ssl_io_hook_read be registered directly with (Open)SSL to
perform the read/write operations - in which case, bailing out is a better
alternative.. Whatever.. 


[snip]
> -
> - /* read filter */
> - ret = apr_bucket_read(pbktIn, &data, &len, (apr_read_type_e)eMode);
> -if (!(eMode == AP_MODE_NONBLOCKING && APR_STATUS_IS_EAGAIN(ret)))
{
> -/* allow retry */
> -APR_BUCKET_REMOVE(pbktIn);
> -}
> - if (ret == APR_SUCCESS && len == 0 && eMode == AP_MODE_BLOCKING)
> - ret = APR_EOF;
> -if (len == 0) {
> -/* Lazy frickin browsers just reset instead of shutting down.
> */
> -/* also gotta handle timeout of keepalive connections */
> -if (ret == APR_EOF || APR_STATUS_IS_ECONNRESET(ret) ||
> -ret == APR_TIMEUP)
> -{
> -if (APR_BRIGADE_EMPTY(pRec->pbbPendingInput))
> - return APR_EOF;
> - else
> - /* Next time around, the incoming brigade will be empty,
> -  * so we'll return EOF then
> -  */
> - return APR_SUCCESS;
> - }
> - 
> [snip]
> 
> Why was this removed ?.. The reason why the (len == 0) checking is being
> done is to take care of browsers like IE, which just closes the connection
> upon termination, or a handshake failure.. 

[snip]
Any errors such as these will be handled by CORE_IN and it will 
pass back the correct error code.  mod_ssl shouldn't do anything 
here.  Remember, previously, it had to handle all of the socket 
code - that is gone now.
[snip]

Tell me if I'm missing something or my eyes are playing tricks here.. Except
for the if (len == 0) loop, I don't see anything much that's missing from
here.. If that's what you're referring, then fine.

[snip]
> -if (bio_is_renegotiating(pRec->pbioRead)) {
> -/* we're doing renegotiation in the access phase */
> -if (len >= *readbytes) {
> -/* trick ap_http_filter into leaving us alone */
> -*readbytes = 0;
> -break; /* SSL_renegotiate will take it from here */
> -}
> -}
> 
> How are the renegotiations handled ?.. SSL doesn't want you to process the
> data when it's in the middle of a renegotiation.. 

This trick doesn't get you anything if you look at the code path.
The renegotiation is handled by the process_connection hook.
[snip]

'not necessarily. The renegotiation request can come from the
ssl_hook_Access() also - in which case ssl_hook_process_connection has no
business whatsoever..


[snip]
Remember - we are only asking for *AT MOST* readbytes.  There is
no contract (this is what Greg and I have been pointing out) that
you will receive exactly readbytes worth of data.  In fact, with
mod_ssl, I'll bet you will often get back less.  But, it definitely
doesn't make sense to try to increase readbytes in mod_ssl to
handle it.  In most cases, I'm going to think that the data will
be an almost 1<->1 comparison (one encyrpted byte may be worth
one unencrypted byte).  So, I don't think it would any value to
try to satisfy the complete readbytes.  We should and often
will send back less than what they asked for. 
[snip]

I generally don't like the idea. It's really a *great* thing to have for
HTTP filters.. But, I have some concerns : 
Some applications may legitimately ask for x bytes, some may ask for a upper
limit of x bytes, and some other may want to have all the data in the
channel (SSL).. 

I'm a novice here and 'obviously missing something - can somebody tell me
why should a application not be given whatever it's asking for - especially
if it's geniune (think SSL) ?..  Also, I guess there has to be a
differentiator b/w a protocol and a application here.. A protocol should to
be given all the data it asks for (and in the format it asks for) - the
interpretation of the data has to be minimal..
It may so happen that a protocol is designed such that it first reads all
the data available and then starts operating on it. I agree that it may be a
bad design - but the requirements may be such - are we telling that such
applications 

Re: [PATCH] mod_ssl input filtering...

[Justin Erenkrantz]

On Thu, Oct 04, 2001 at 05:12:10PM -0400, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) 
wrote:

[ Have a few minutes before class starts... ]

> -if (ssl == NULL) {
> -return -1;
> -}
> -
> [snip]
> 
> 
> => Why is the checking not required ?.. If it's justified, then the
> corresponding check has to be eliminated from ssl_io_hook_write() also..

Yeah, it should be removed from ssl_io_hook_write as well.  But,
I wasn't changing that function.  =)  Checking for null on something
like this isn't our preferred style - if it is NULL, then something
really bad happened anyway.  (ssl can't be null under any normal
circumstances here if you see how the code is called - it just
doesn't add any value...)

> -
> - /* read filter */
> - ret = apr_bucket_read(pbktIn, &data, &len, (apr_read_type_e)eMode);
> -if (!(eMode == AP_MODE_NONBLOCKING && APR_STATUS_IS_EAGAIN(ret))) {
> -/* allow retry */
> -APR_BUCKET_REMOVE(pbktIn);
> -}
> - if (ret == APR_SUCCESS && len == 0 && eMode == AP_MODE_BLOCKING)
> - ret = APR_EOF;
> -if (len == 0) {
> -/* Lazy frickin browsers just reset instead of shutting down.
> */
> -/* also gotta handle timeout of keepalive connections */
> -if (ret == APR_EOF || APR_STATUS_IS_ECONNRESET(ret) ||
> -ret == APR_TIMEUP)
> -{
> -if (APR_BRIGADE_EMPTY(pRec->pbbPendingInput))
> - return APR_EOF;
> - else
> - /* Next time around, the incoming brigade will be empty,
> -  * so we'll return EOF then
> -  */
> - return APR_SUCCESS;
> - }
> - 
> [snip]
> 
> Why was this removed ?.. The reason why the (len == 0) checking is being
> done is to take care of browsers like IE, which just closes the connection
> upon termination, or a handshake failure.. 

No, that should all be handled by other people in other places.
If the socket is closed, that is job of the lower level filters
to take care of.  mod_ssl should now only concern itself with
data that was read by the core - this was an assumption about
the socket interface that it has no business knowing about.
At least, that is my operative theory.  

Any errors such as these will be handled by CORE_IN and it will 
pass back the correct error code.  mod_ssl shouldn't do anything 
here.  Remember, previously, it had to handle all of the socket 
code - that is gone now.

> [snip]
> - if (eMode != AP_MODE_NONBLOCKING)
> - ap_log_error(APLOG_MARK,APLOG_ERR,ret,NULL,
> -  "Read failed in ssl input filter");
> -
> - if ((eMode == AP_MODE_NONBLOCKING) &&
> -(APR_STATUS_IS_SUCCESS(ret) || APR_STATUS_IS_EAGAIN(ret)))
> -{
> -/* In this case, we have data in the output bucket, or we
> were
> - * non-blocking, so returning nothing is fine.
> - */
> -return APR_SUCCESS;
> -}
> -else {
> -return ret;
> -}
> - }
> [snip]
> 
> Again - why is it deleted ?.. This is also *required* when
> AP_MODE_NONBLOCKING is set to true - pl. justify.

No, that's not necessarily true.  You were previously reading directly
from the socket bucket - you would have to handle EAGAIN and other
cases, but that's just not a valid assumption here.  We shouldn't
be concerning ourselves with what the bucket type is at all.
In fact, BLOCKING or NONBLOCKING just doesn't really matter to
anyone other than the person reading from the raw socket - which
mod_ssl no longer does - only the core can read from the socket.
And, in fact, CORE_IN probably won't use the socket bucket for much
longer.

> [snip]
> -if (bio_is_renegotiating(pRec->pbioRead)) {
> -/* we're doing renegotiation in the access phase */
> -if (len >= *readbytes) {
> -/* trick ap_http_filter into leaving us alone */
> -*readbytes = 0;
> -break; /* SSL_renegotiate will take it from here */
> -}
> -}
> [snip]
> 
> How are the renegotiations handled ?.. SSL doesn't want you to process the
> data when it's in the middle of a renegotiation.. 

This trick doesn't get you anything if you look at the code path.
The renegotiation is handled by the process_connection hook.

The idea is that we are reading everything we can possibly read
into the BIO (up to *readbytes or whatever may already be in 
ctx->rawb) and then we'll let OpenSSL determine what to do with 
it.  We'll extract the unencrypted information from OpenSSL via 
SSL_read.

If it returns READ_MORE, we could retry, but I don't think we
need to do so.  The higher level filters (i.e. request filters)
need to handle that retry.

> [snip]
> +/* Readbytes == 0 implies we only want a LF line. 
> + * 1024 seems like a good number

Re: [PATCH] Remove the Port directive.

[Ian Kallen <[EMAIL PROTECTED]>]

I don't vote on this craziness but I've always thought the overlap of
Port, ServerName, Listen and BindAddress was severely hideous so fwiw,
bravo for striking Port.

My original motivation for patching the old configure script to handle
--with-port was for the course I teach: I introduce students to apache by
doing the minimal precompile configuration just to get something running
out of the asf tarball.  Then, of course, I start introducing them to all
that is evil and loathsome in httpd.conf -- please, whatever you do,
continue the precompile configuration behavior of enabling a working
Apache.  IMO, the minimal bootstrap steps should continue to be
./configure --with-port=MY_ASSIGNED_PORT --prefix=$HOME/apache
make && make install
cd $HOME/apache
./bin/apachectl start

Ta-da!

On Thu, 4 Oct 2001, Aaron Bannert wrote:

> On Thu, Oct 04, 2001 at 11:43:40AM -0700, Justin Erenkrantz wrote:
> > I sort of agree with Aaron about run-time configuration options, but
> > not enough that I want to edit files manually.  =)
> 
> I don't want to have to edit them manually either, but I end up doing it
> anyway.
> 
> > This concept has always been a topic of debate between Aaron and
> > myself - we talked about this for a long time when we did flood.
> > I'd be curious to see what other people think.
> > 
> > I think build-time options can specify the defaults - they can
> > always be overriden later...  -- justin
> 
> That is the trouble with this, it is very alluring to have it all fall into
> place at "make install"-time, but it's hard to see how that can be a problem
> from our perspective.
> 
> -aaron
> 

cheers,
-Ian

--
Ian Kallen <[EMAIL PROTECTED]> | AIM: iankallen

Re: [PATCH] Remove the Port directive.

[Ryan Bloom]

On Thursday 04 October 2001 03:12 pm, dean gaudet wrote:

> if a "NameVirtualHost Foo.Com" directive is present, and there are no
> other vhost sections then it'll warn that there's a NameVirtualHost
> without any vhosts.
>
> > The default port is 80, but we do not default a listening port
> > anymore.
>
> so this means an httpd.conf with "Listen 80", but no ServerName directive
> and no vhosts would JFW, right?  (i.e. the ServerName would end up
> defaulting to the gethostname() result, and the port would default to 80.)

That was my test case, and it does JFW.

Ryan
__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: [PATCH] Remove the Port directive.

[dean gaudet]

On Thu, 4 Oct 2001, Ryan Bloom wrote:

> On Thursday 04 October 2001 08:50 am, Rodent of Unusual Size wrote:
>
> > Listen 80
> > ServerName Foo.Com
> > 
> >
> > What happens?  Presumably the vhost will never hear anything,
> > but will/should we detect it and report it?
>
> We don't today.  Should we, probably.  This patch does not touch this
> logic though.

in the absense of a "NameVirtualHost Foo.Com" directive, the above doesn't
generate a warning in 1.3... (although it does if you select the dump
vhosts command line option, odd that i didn't put the warning into normal
runs!)

if a "NameVirtualHost Foo.Com" directive is present, and there are no
other vhost sections then it'll warn that there's a NameVirtualHost
without any vhosts.

> The default port is 80, but we do not default a listening port
> anymore.

so this means an httpd.conf with "Listen 80", but no ServerName directive
and no vhosts would JFW, right?  (i.e. the ServerName would end up
defaulting to the gethostname() result, and the port would default to 80.)

+1 if so.

-dean

RE: [PATCH] Remove the Port directive - affects SSL vhost config

[Sander Striker]

> From: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
> Sent: 04 October 2001 22:40

> The patch just affects SSL configurations also.. The ServerName directive
> specified within a Virtual Host configuration HAS to be accompanied by the
> SSL port, or else, the server assumes the port 80 by default :-(..
>
> -Madhu

How hard is it to return the port that was connected to?  That seems to be
a logical solution.  Thoughts?

Sander

RE: [PATCH] mod_ssl input filtering...

[MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)]

Hi,
Pl. find my comments below :

[snip]
Index: modules/ssl/ssl_engine_io.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_io.c,v
retrieving revision 1.37
diff -u -r1.37 ssl_engine_io.c
--- modules/ssl/ssl_engine_io.c 2001/10/04 17:50:39 1.37
+++ modules/ssl/ssl_engine_io.c 2001/10/04 19:54:22
@@ -72,14 +72,10 @@
 
 static const char ssl_io_filter[] = "SSL/TLS Filter";
 
-static int ssl_io_hook_read(SSL *ssl, unsigned char *buf, int len)
+static int ssl_io_hook_read(SSL *ssl, char *buf, int len)
 {
 int rc;
 
-if (ssl == NULL) {
-return -1;
-}
-
[snip]


=> Why is the checking not required ?.. If it's justified, then the
corresponding check has to be eliminated from ssl_io_hook_write() also..


[snip] 
-
-   /* read filter */
-   ret = apr_bucket_read(pbktIn, &data, &len, (apr_read_type_e)eMode);
-if (!(eMode == AP_MODE_NONBLOCKING && APR_STATUS_IS_EAGAIN(ret))) {
-/* allow retry */
-APR_BUCKET_REMOVE(pbktIn);
-}
-   if (ret == APR_SUCCESS && len == 0 && eMode == AP_MODE_BLOCKING)
-   ret = APR_EOF;
-if (len == 0) {
-/* Lazy frickin browsers just reset instead of shutting down.
*/
-/* also gotta handle timeout of keepalive connections */
-if (ret == APR_EOF || APR_STATUS_IS_ECONNRESET(ret) ||
-ret == APR_TIMEUP)
-{
-if (APR_BRIGADE_EMPTY(pRec->pbbPendingInput))
-   return APR_EOF;
-   else
-   /* Next time around, the incoming brigade will be empty,
-* so we'll return EOF then
-*/
-   return APR_SUCCESS;
-   }
-   
[snip]

Why was this removed ?.. The reason why the (len == 0) checking is being
done is to take care of browsers like IE, which just closes the connection
upon termination, or a handshake failure.. 

[snip]
-   if (eMode != AP_MODE_NONBLOCKING)
-   ap_log_error(APLOG_MARK,APLOG_ERR,ret,NULL,
-"Read failed in ssl input filter");
-
-   if ((eMode == AP_MODE_NONBLOCKING) &&
-(APR_STATUS_IS_SUCCESS(ret) || APR_STATUS_IS_EAGAIN(ret)))
-{
-/* In this case, we have data in the output bucket, or we
were
- * non-blocking, so returning nothing is fine.
- */
-return APR_SUCCESS;
-}
-else {
-return ret;
-}
-   }
[snip]

Again - why is it deleted ?.. This is also *required* when
AP_MODE_NONBLOCKING is set to true - pl. justify.


[snip]
-if (bio_is_renegotiating(pRec->pbioRead)) {
-/* we're doing renegotiation in the access phase */
-if (len >= *readbytes) {
-/* trick ap_http_filter into leaving us alone */
-*readbytes = 0;
-break; /* SSL_renegotiate will take it from here */
-}
-}
[snip]

How are the renegotiations handled ?.. SSL doesn't want you to process the
data when it's in the middle of a renegotiation.. 

[snip]
+/* Readbytes == 0 implies we only want a LF line. 
+ * 1024 seems like a good number for now. */
+*tempread = 1024; 
[snip]

WHAT ?.. SSL is pretty different from the way HTTP works.. During a SSL
handshake, there's a tightly coupled message exchange that goes on b/w
client and server.. client sends something, server interprets and sends back
something, client interprets and communicates back and so on.. 
The actual size of the data communicated in each phase depends upon the
cert. size, the ciphers available and various other parameters.. You can
never assume that x bytes will be communicated during a phase phase.. (1024
- is a assumption according to me)..
So, if SSL asks for more data (SSL_ERROR_WANT_READ), it means that it wants
*all* the data that's available in the buffer.. If it get buffer less than
the size it is expecting, then it just cries for more data.. We *have* to
handle that condition - understand *how much* more data is it asking for..
The information is *already* available in the SSL context - but I'm afraid
to use them directly.. There should be some API that should tell *how much*
data is SSL expecting from the communication channel.

PS : SSL gurus - pl. correct me if I'm wrong anywhere..

Thx
-Madhu

infinite recursive subrequests

[Greg Ames]

...well, at least until my ulimit of 1024 open file descriptors kicks
in.

setup: DocumentRoot contains /index.html, mod_negotiation is built in,
Options MultiViews is coded in the config file.  Directory
/index/ does not exist.

URI: /index/garbage/trash (the /trash on the end is probably irrelevant)

We get into read_types_multi() in mod_negotiation's type checker.  It
has r->filename == /index and neg->dir_name ==  ,
opens up the doc_root directory, and starts reading entries.  The entry
for "index.html" triggers a call to ap_sub_req_lookup_dir_ent(), which
starts the nearly infinite recursion.  The subrequest URI's are
/index/garbage/index.html .  

Thankfully, my ulimit kicks in when mod_negotiation has 1011 open fd's
for the doc_root directory.  Then I get a single 

"(24)Too many open files: cannot read directory for multi: " 

log message, followed by 1011 

"Negotiation: discovered file(s) matching request: /index
(None could be negotiated)"

log messages.

It seems like this code is confused about what the base part of the
desired pathname is, and uses only the part that exists (doc_root) in
the code that opens the directory.  This is wrong.  Since neg->dir_name
isn't the same as the desired pathname up to the last slash, some code
must have already detected a problem, but didn't kill the request.  Or
shouldn't the request die in directory_walk?

Greg

Re: [PATCH] some fixes for ap_http_filter

[Aaron Bannert]

On Thu, Oct 04, 2001 at 01:29:26PM -0700, Ryan Bloom wrote:
> > > -if (!ctx->remaining)
> > > -{
> > > +if (ctx->remaining <= 0) {
> >
> > No.  =)  Java weenie.
> 
> Huh?  How is this him being a Java weenie?  Aaron has changed a check
> for !0 to a check for negative or 0.  Those two checks are not equivalent.
> I'm not sure if this is a valid change or not yet, but I am wondering what the
> comment is about.

[To Justin]

Even if we were checking for zero/non-zero, I would want it to be

(ctx->remaining ==/!= 0)

We are not checking the boolean status of the variable, we are checking
the integer status. Shorthand does not equate to fewer instructions
and sometimes defeats readability.

-aaron

Re: [PATCH] some fixes for ap_http_filter

[Ian Holsman]

Aaron Bannert wrote:

> On Thu, Oct 04, 2001 at 01:14:31PM -0700, Justin Erenkrantz wrote:
> 
>>On Thu, Oct 04, 2001 at 12:52:17PM -0700, Aaron Bannert wrote:
>>
>>>I came across a few things that needed attention in my review of the
>>>http filter code:
>>>
>>Cool.
>>
> 
> [hey! Aren't you supposed to be in class? ;) ]


I've been debugging the proxy problem with the input filters, and it also seems
to be screwing up in this function as well.

The proxy calls this function with a NULL request in the input filter,
causing the pool-alloc to fail (invalid access)

by the looks of it the 'request' variable in the input_filters stucture
is NULL all the way back in process_connection.

I was wondering how this happens?
(BTW.. this stuff was working with the CVS of Sep-20, before the input filter changes
went in)

> 
> 
>>>- ctx->remaining was uninitialized.
>>>
>>We don't care what ctx->remaining is unless we have a special
>>parsing type which sets ctx->remaining.  But, yeah, this may
>>make more sense with my below comment...
>>
> 
> It seemed to me that we were making assumptions about our input. There
> were code paths that could be reached where ctx->remaining would be
> used before being initialized.
> 
> 
>>>- I'm a little uncomfortable with the Content-Length: parsing, please
>>>  see my comments in the diff.
>>>
>>I didn't touch that loop.  =)  But, yeah, once we see a digit,
>>we should read until we don't see a digit.
>>
> 
> I don't really know where the loop came from, I just wanna make sure it's
> safe. (more comments below)
> 
> 
>>>- a logic reduction in a do-while loop (reduces the number of times
>>>  we call APR_BRIGADE_EMPTY by half).
>>>- made the ctx->remaining condition check more robust.
>>>
>>We should never return more than ctx->remaining.  That's the whole
>>point.  =)  So, checking it for negative value may not be necessary.
>>In fact, if it is negative, we have major problems.  If you want
>>to place an assert there - because it should never happen...
>>
> 
> "should" being the operative word here. It was not obvious to me how
> we ensure ctx->remaining is always non-negative. We are trusting our
> input variables on a filter where we aren't supposed to know what our
> neighbors are. Maybe I've missed some crutial piece of logic that
> would quell my fears, but robust >= reliable. :)
> 
> 
>>Some quick comments inline...
>>
>>
>>>Index: modules/http/http_protocol.c
>>>===
>>>RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
>>>retrieving revision 1.369
>>>diff -u -r1.369 http_protocol.c
>>>--- modules/http/http_protocol.c 2001/10/02 21:13:41 1.369
>>>+++ modules/http/http_protocol.c 2001/10/04 18:34:25
>>>@@ -504,6 +504,7 @@
>>> if (!ctx) {
>>> const char *tenc, *lenp;
>>> f->ctx = ctx = apr_palloc(f->r->pool, sizeof(*ctx));
>>>+ctx->remaining = 0;
>>> ctx->state = BODY_NONE;
>>> 
>>> tenc = apr_table_get(f->r->headers_in, "Transfer-Encoding");
>>>@@ -523,26 +524,32 @@
>>> else if (lenp) {
>>> const char *pos = lenp;
>>> 
>>>+/* XXX: Is this safe? I can do "Content-Length: 3 3 3" ... */
>>> while (apr_isdigit(*pos) || apr_isspace(*pos))
>>> ++pos;
>>> if (*pos == '\0') {
>>> ctx->state = BODY_LENGTH;
>>> ctx->remaining = atol(lenp);
>>>+/* XXX: Are there any platforms where apr_off_t != long?
>>>+aka: Would it be possible to overflow here? */
>>>+/* XXX: Can we get here with an invalid number? (ie <0) */
>>>
>>As I said, this was just copied from the content-length parsing routines
>>we already had.  So, possibly.  =)
>>
> 
> No prob, just bringing it to our attention.
> I thought it was kind of neat that I could do:
> 
> curl -H "Content-Length: 3 3 3 3 3 3 3 3 3" -d "foo" [some url] and it
> would work fine. This part is NBD ("flexible on input, strict on output"),
> I'm really much more concerned about the implicit type cast from a long
> to an off_t (apr_off_t). What would happen if we had a platform where
> those didn't match, and someone could get an overflow (and potentially
> a negative number) into ctx->remaining? Would bad things happen? That's
> why I made the next change:
> 
> 
> 
>>> }
>>> }
>>> }
>>> 
>>>-if (!ctx->remaining)
>>>+if (ctx->remaining <= 0)
>>>
>>I think this negative check is a bit bogus for reasons above...
>>
> 
> They are both logically correct, but now it makes fewer assumptions
> about the input.
> 
> 
>>> {
>>> switch (ctx->state)
>>> {
>>> case BODY_NONE:
>>> break;
>>> case BODY_LENGTH:
>>>+/* We've already consumed the Content-length size, so flush. */
>>> e = apr_bucket_eos_create();
>>> APR_BRIGADE_INSERT_TAIL(b, e);
>>> retu

Re: [PATCH] some fixes for ap_http_filter

[Aaron Bannert]

On Thu, Oct 04, 2001 at 01:14:31PM -0700, Justin Erenkrantz wrote:
> On Thu, Oct 04, 2001 at 12:52:17PM -0700, Aaron Bannert wrote:
> > I came across a few things that needed attention in my review of the
> > http filter code:
> 
> Cool.

[hey! Aren't you supposed to be in class? ;) ]

> > - ctx->remaining was uninitialized.
> 
> We don't care what ctx->remaining is unless we have a special
> parsing type which sets ctx->remaining.  But, yeah, this may
> make more sense with my below comment...

It seemed to me that we were making assumptions about our input. There
were code paths that could be reached where ctx->remaining would be
used before being initialized.

> > - I'm a little uncomfortable with the Content-Length: parsing, please
> >   see my comments in the diff.
> 
> I didn't touch that loop.  =)  But, yeah, once we see a digit,
> we should read until we don't see a digit.

I don't really know where the loop came from, I just wanna make sure it's
safe. (more comments below)

> > - a logic reduction in a do-while loop (reduces the number of times
> >   we call APR_BRIGADE_EMPTY by half).
> > - made the ctx->remaining condition check more robust.
> 
> We should never return more than ctx->remaining.  That's the whole
> point.  =)  So, checking it for negative value may not be necessary.
> In fact, if it is negative, we have major problems.  If you want
> to place an assert there - because it should never happen...

"should" being the operative word here. It was not obvious to me how
we ensure ctx->remaining is always non-negative. We are trusting our
input variables on a filter where we aren't supposed to know what our
neighbors are. Maybe I've missed some crutial piece of logic that
would quell my fears, but robust >= reliable. :)

> Some quick comments inline...
> 
> > Index: modules/http/http_protocol.c
> > ===
> > RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
> > retrieving revision 1.369
> > diff -u -r1.369 http_protocol.c
> > --- modules/http/http_protocol.c2001/10/02 21:13:41 1.369
> > +++ modules/http/http_protocol.c2001/10/04 18:34:25
> > @@ -504,6 +504,7 @@
> >  if (!ctx) {
> >  const char *tenc, *lenp;
> >  f->ctx = ctx = apr_palloc(f->r->pool, sizeof(*ctx));
> > +ctx->remaining = 0;
> >  ctx->state = BODY_NONE;
> >  
> >  tenc = apr_table_get(f->r->headers_in, "Transfer-Encoding");
> > @@ -523,26 +524,32 @@
> >  else if (lenp) {
> >  const char *pos = lenp;
> >  
> > +/* XXX: Is this safe? I can do "Content-Length: 3 3 3" ... */
> >  while (apr_isdigit(*pos) || apr_isspace(*pos))
> >  ++pos;
> >  if (*pos == '\0') {
> >  ctx->state = BODY_LENGTH;
> >  ctx->remaining = atol(lenp);
> > +/* XXX: Are there any platforms where apr_off_t != long?
> > +aka: Would it be possible to overflow here? */
> > +/* XXX: Can we get here with an invalid number? (ie <0) */
> 
> As I said, this was just copied from the content-length parsing routines
> we already had.  So, possibly.  =)

No prob, just bringing it to our attention.
I thought it was kind of neat that I could do:

curl -H "Content-Length: 3 3 3 3 3 3 3 3 3" -d "foo" [some url] and it
would work fine. This part is NBD ("flexible on input, strict on output"),
I'm really much more concerned about the implicit type cast from a long
to an off_t (apr_off_t). What would happen if we had a platform where
those didn't match, and someone could get an overflow (and potentially
a negative number) into ctx->remaining? Would bad things happen? That's
why I made the next change:


> >  }
> >  }
> >  }
> >  
> > -if (!ctx->remaining)
> > +if (ctx->remaining <= 0)
> 
> I think this negative check is a bit bogus for reasons above...

They are both logically correct, but now it makes fewer assumptions
about the input.

> >  {
> >  switch (ctx->state)
> >  {
> >  case BODY_NONE:
> >  break;
> >  case BODY_LENGTH:
> > +/* We've already consumed the Content-length size, so flush. */
> >  e = apr_bucket_eos_create();
> >  APR_BRIGADE_INSERT_TAIL(b, e);
> >  return APR_SUCCESS;
> >  case BODY_CHUNK:
> > +/* Done with this chunk, go get the next chunk length. */
> >  {
> >  char line[30];
> >  
> > @@ -560,8 +567,7 @@
> >  ctx->state = BODY_CHUNK;
> >  ctx->remaining = get_chunk_size(line);
> >  
> > -if (!ctx->remaining)
> > -{
> > +if (ctx->remaining <= 0) {
> 
> No.  =)  Java weenie.

Who's the Java weenie? This is the same change as above with the additional
benefit of meeting our style guide.

(btw, Where do 

RE: [PATCH] Remove the Port directive - affects SSL vhost config

[MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)]

The patch just affects SSL configurations also.. The ServerName directive
specified within a Virtual Host configuration HAS to be accompanied by the
SSL port, or else, the server assumes the port 80 by default :-(..

-Madhu

-Original Message-
From: Ryan Bloom [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 04, 2001 11:49 AM
To: Justin Erenkrantz
Cc: [EMAIL PROTECTED]
Subject: Re: [PATCH] Remove the Port directive.


On Thursday 04 October 2001 11:43 am, Justin Erenkrantz wrote:
> On Thu, Oct 04, 2001 at 11:38:30AM -0700, Ryan Bloom wrote:
> > It should already support that.  The @@Port@@ in the httpd-std.conf
> > is what does that.
>
> Correct me if I'm wrong, but your patch has:
>
> -# Port: The port to which the standalone server listens. For
> -# ports < 1023, you will need httpd to be run as root initially.
> -#
> -Port @@Port@@
>
> What I'm suggesting is adding:
>
> Listen @@Port@@

Take a look at the file as it exists today.  This change was made
yesterday.

Ryan
__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: [PATCH] some fixes for ap_http_filter

[Ryan Bloom]

On Thursday 04 October 2001 01:14 pm, Justin Erenkrantz wrote:

> >  ctx->state = BODY_CHUNK;
> >  ctx->remaining = get_chunk_size(line);
> >
> > -if (!ctx->remaining)
> > -{
> > +if (ctx->remaining <= 0) {
>
> No.  =)  Java weenie.

Huh?  How is this him being a Java weenie?  Aaron has changed a check
for !0 to a check for negative or 0.  Those two checks are not equivalent.
I'm not sure if this is a valid change or not yet, but I am wondering what the
comment is about.

> > -if (ctx->state != BODY_NONE)
> > +if (ctx->state != BODY_NONE) {
>
> No need for braces here...

Braces are good programming style, whether they are needed or not.
It makes it far less likely that somebody will forget to add them later when
they are necessary.

Ryan

__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: [PATCH] [Resubmit] Re: Tagging 1.3.21 now

[Jim Jagielski]

Dirk-Willem van Gulik wrote:
> 
> 
> 
> On Thu, 4 Oct 2001, Bill Stoddard wrote:
> 
> > Committed and tag moved to pick up the change in 1.3.21
> 
> Do you really really want to do this ?
> 
> In the past those sort of last minute changes have proven to cause endless
> havoc - and it was easier to just skip a version number.
> 

I would think the fact that a tarball was not created makes trying to
retag a bit easier to swallow.

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

Re: [PATCH] some fixes for ap_http_filter

[Justin Erenkrantz]

On Thu, Oct 04, 2001 at 12:52:17PM -0700, Aaron Bannert wrote:
> I came across a few things that needed attention in my review of the
> http filter code:

Cool.

> - ctx->remaining was uninitialized.

We don't care what ctx->remaining is unless we have a special
parsing type which sets ctx->remaining.  But, yeah, this may
make more sense with my below comment...

> - I'm a little uncomfortable with the Content-Length: parsing, please
>   see my comments in the diff.

I didn't touch that loop.  =)  But, yeah, once we see a digit,
we should read until we don't see a digit.

> - a logic reduction in a do-while loop (reduces the number of times
>   we call APR_BRIGADE_EMPTY by half).
> - made the ctx->remaining condition check more robust.

We should never return more than ctx->remaining.  That's the whole
point.  =)  So, checking it for negative value may not be necessary.
In fact, if it is negative, we have major problems.  If you want
to place an assert there - because it should never happen...

Some quick comments inline...

> Index: modules/http/http_protocol.c
> ===
> RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
> retrieving revision 1.369
> diff -u -r1.369 http_protocol.c
> --- modules/http/http_protocol.c  2001/10/02 21:13:41 1.369
> +++ modules/http/http_protocol.c  2001/10/04 18:34:25
> @@ -504,6 +504,7 @@
>  if (!ctx) {
>  const char *tenc, *lenp;
>  f->ctx = ctx = apr_palloc(f->r->pool, sizeof(*ctx));
> +ctx->remaining = 0;
>  ctx->state = BODY_NONE;
>  
>  tenc = apr_table_get(f->r->headers_in, "Transfer-Encoding");
> @@ -523,26 +524,32 @@
>  else if (lenp) {
>  const char *pos = lenp;
>  
> +/* XXX: Is this safe? I can do "Content-Length: 3 3 3" ... */
>  while (apr_isdigit(*pos) || apr_isspace(*pos))
>  ++pos;
>  if (*pos == '\0') {
>  ctx->state = BODY_LENGTH;
>  ctx->remaining = atol(lenp);
> +/* XXX: Are there any platforms where apr_off_t != long?
> +aka: Would it be possible to overflow here? */
> +/* XXX: Can we get here with an invalid number? (ie <0) */

As I said, this was just copied from the content-length parsing routines
we already had.  So, possibly.  =)

>  }
>  }
>  }
>  
> -if (!ctx->remaining)
> +if (ctx->remaining <= 0)

I think this negative check is a bit bogus for reasons above...

>  {
>  switch (ctx->state)
>  {
>  case BODY_NONE:
>  break;
>  case BODY_LENGTH:
> +/* We've already consumed the Content-length size, so flush. */
>  e = apr_bucket_eos_create();
>  APR_BRIGADE_INSERT_TAIL(b, e);
>  return APR_SUCCESS;
>  case BODY_CHUNK:
> +/* Done with this chunk, go get the next chunk length. */
>  {
>  char line[30];
>  
> @@ -560,8 +567,7 @@
>  ctx->state = BODY_CHUNK;
>  ctx->remaining = get_chunk_size(line);
>  
> -if (!ctx->remaining)
> -{
> +if (ctx->remaining <= 0) {

No.  =)  Java weenie.

>  /* Handle trailers by calling get_mime_headers again! */
>  e = apr_bucket_eos_create();
>  APR_BRIGADE_INSERT_TAIL(b, e);
> @@ -572,13 +578,13 @@
>  }
>  }
>  
> -rv = ap_get_brigade(f->next, b, mode, readbytes);
> -
> -if (rv != APR_SUCCESS)
> +if ((rv = ap_get_brigade(f->next, b, mode, readbytes)) != APR_SUCCESS) {
>  return rv;
> +}

I don't like this style.  Blech.  It makes the line too long...

>  
> -if (ctx->state != BODY_NONE)
> +if (ctx->state != BODY_NONE) {

No need for braces here...

>  ctx->remaining -= *readbytes;
> +}
>  
>  return APR_SUCCESS;
>  }
> @@ -1360,19 +1366,17 @@
>  &core_module);
>  apr_bucket_brigade *bb = req_cfg->bb;
>  
> -do {
> -if (APR_BRIGADE_EMPTY(bb)) {
> -if (ap_get_brigade(r->input_filters, bb, AP_MODE_BLOCKING,
> -   &r->remaining) != APR_SUCCESS) {
> -/* if we actually fail here, we want to just return and
> - * stop trying to read data from the client.
> - */
> -r->connection->keepalive = -1;
> -apr_brigade_destroy(bb);
> -return -1;
> -}
> +while (APR_BRIGADE_EMPTY(bb)) {
> +if (ap_get_brigade(r->input_filters, bb, AP_MODE_BLOCKING,
> +   &r->remaining) != APR_SUCCESS) {
> +/* if we actually fail here, we want to just return and
> + * stop trying to read data from the client.
> +

Re: mod_rewrite.c adding X-Forwarded-For for proxy requests

[Thomas Eibner]

On Thu, Oct 04, 2001 at 11:55:42AM -0700, Josh Goldberg wrote:
> I'm new around here, so please correct me if this is the wrong list.  I was having 
>trouble with my weblogs only seeing my reverse proxy server as the referrer, so I 
>integrated Bjoern Hansen's proxy_add_forward module functionality into the proxy 
>section of mod_rewrite.  Below is diff of CVS rev. 1.172 against my module.

If it was to be put in there mod_rewrite probably wouldn't be the place
to put it (IMO). mod_proxy is where it belongs.

What are you using to get it the other way around on your backend? I made
a little module that does the opposite of mod_proxy_add_forward, it's
called mod_rpaf and you can find it on http://stderr.net/apache/rpaf/

-- 
  Thomas Eibner  DnsZone 
  mod_pointer  

[PATCH] mod_ssl input filtering...

[Justin Erenkrantz]

I have to get to class now.

This is within shouting distance of where we need to be.  
It compiles.  =)  Yet another gnarly patch.  Oh, well.

I also moved some code from mod_ssl.c that dealt with buckets into 
ssl_engine_io.c.  That seems logical to do though.

Oh, when we enter churn with data in ctx->b, we need to ensure that 
we don't send too much - ctx->b length is more than readbytes - call 
partition...  That shouldn't be too hard to add...

I'll be back around 7 or 8pm tonight (if not later).  I'd appreciate 
it if someone else could look at this and see if they can test it or 
even make it work (and possibly repost or commit it!).

Later...  -- justin

Index: modules/ssl/mod_ssl.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/mod_ssl.c,v
retrieving revision 1.30
diff -u -r1.30 mod_ssl.c
--- modules/ssl/mod_ssl.c   2001/08/30 05:33:57 1.30
+++ modules/ssl/mod_ssl.c   2001/10/04 19:54:22
@@ -73,8 +73,6 @@
 AP_INIT_##args("SSL"#name, ssl_cmd_SSL##name, NULL, OR_##type, desc),
 #define AP_END_CMD { NULL }
 
-#define HTTP_ON_HTTPS_PORT "GET /mod_ssl:error:HTTP-request HTTP/1.0\r\n"
-
 static const command_rec ssl_config_cmds[] = {
 
 /*
@@ -369,41 +367,9 @@
 /*
  * The case where OpenSSL has recognized a HTTP request:
  * This means the client speaks plain HTTP on our HTTPS port.
- * H...  At least for this error we can be more friendly
- * and try to provide him with a HTML error page. We have only
- * one problem:OpenSSL has already read some bytes from the HTTP
- * request. So we have to skip the request line manually and
- * instead provide a faked one in order to continue the internal
- * Apache processing.
- *
+ * H...  Punt this out of here after removing our output
+ * filter.
  */
-apr_bucket *e;
-const char *str;
-apr_size_t len;
-/* log the situation */
-ssl_log(c->base_server, SSL_LOG_ERROR|SSL_ADD_SSLERR,
-"SSL handshake failed: HTTP spoken on HTTPS port; "
-"trying to send HTML error page");
-
-/* fake the request line */
-e = apr_bucket_immortal_create(HTTP_ON_HTTPS_PORT, 
-   strlen(HTTP_ON_HTTPS_PORT));
-APR_BRIGADE_INSERT_HEAD(pRec->pbbPendingInput, e);
-
-APR_BRIGADE_FOREACH(e, pRec->pbbInput) {
-apr_bucket_read(e, &str, &len, APR_NONBLOCK_READ);
-if (len) {
-APR_BUCKET_REMOVE(e);
-APR_BRIGADE_INSERT_TAIL(pRec->pbbPendingInput, e);
-if ((strcmp(str, "\r\n") == 0) ||
-(ap_strstr_c(str, "\r\n\r\n"))) {
-break;
-}
-}
-}
-e = APR_BRIGADE_LAST(pRec->pbbInput);
-APR_BUCKET_REMOVE(e);
-
 ap_remove_output_filter(pRec->pOutputFilter);
 return HTTP_BAD_REQUEST;
 }
Index: modules/ssl/mod_ssl.h
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/mod_ssl.h,v
retrieving revision 1.33
diff -u -r1.33 mod_ssl.h
--- modules/ssl/mod_ssl.h   2001/09/10 04:21:40 1.33
+++ modules/ssl/mod_ssl.h   2001/10/04 19:54:22
@@ -442,8 +442,8 @@
 BIO*pbioWrite;
 ap_filter_t*pInputFilter;
 ap_filter_t*pOutputFilter;
-apr_bucket_brigade *pbbInput;/* encrypted input */
-apr_bucket_brigade *pbbPendingInput; /* decrypted input */
+apr_bucket_brigade *rawb;   /* encrypted input */
+apr_bucket_brigade *b;  /* decrypted input */
 } SSLFilterRec;
 
 typedef struct {
Index: modules/ssl/ssl_engine_io.c
===
RCS file: /home/cvs/httpd-2.0/modules/ssl/ssl_engine_io.c,v
retrieving revision 1.37
diff -u -r1.37 ssl_engine_io.c
--- modules/ssl/ssl_engine_io.c 2001/10/04 17:50:39 1.37
+++ modules/ssl/ssl_engine_io.c 2001/10/04 19:54:22
@@ -72,14 +72,10 @@
 
 static const char ssl_io_filter[] = "SSL/TLS Filter";
 
-static int ssl_io_hook_read(SSL *ssl, unsigned char *buf, int len)
+static int ssl_io_hook_read(SSL *ssl, char *buf, int len)
 {
 int rc;
 
-if (ssl == NULL) {
-return -1;
-}
-
 rc = SSL_read(ssl, buf, len);
 
 if (rc < 0) {
@@ -189,75 +185,48 @@
 
 #define bio_is_renegotiating(bio) \
 (((int)BIO_get_callback_arg(bio)) == SSL_ST_RENEGOTIATE)
+#define HTTP_ON_HTTPS_PORT "GET /mod_ssl:error:HTTP-request HTTP/1.0\r\n\r\n"
 
-static apr_statu

[PATCH] some fixes for ap_http_filter

[Aaron Bannert]

I came across a few things that needed attention in my review of the
http filter code:

- ctx->remaining was uninitialized.
- I'm a little uncomfortable with the Content-Length: parsing, please
  see my comments in the diff.
- a logic reduction in a do-while loop (reduces the number of times
  we call APR_BRIGADE_EMPTY by half).
- made the ctx->remaining condition check more robust.

-aaron


Index: modules/http/http_protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.369
diff -u -r1.369 http_protocol.c
--- modules/http/http_protocol.c2001/10/02 21:13:41 1.369
+++ modules/http/http_protocol.c2001/10/04 18:34:25
@@ -504,6 +504,7 @@
 if (!ctx) {
 const char *tenc, *lenp;
 f->ctx = ctx = apr_palloc(f->r->pool, sizeof(*ctx));
+ctx->remaining = 0;
 ctx->state = BODY_NONE;
 
 tenc = apr_table_get(f->r->headers_in, "Transfer-Encoding");
@@ -523,26 +524,32 @@
 else if (lenp) {
 const char *pos = lenp;
 
+/* XXX: Is this safe? I can do "Content-Length: 3 3 3" ... */
 while (apr_isdigit(*pos) || apr_isspace(*pos))
 ++pos;
 if (*pos == '\0') {
 ctx->state = BODY_LENGTH;
 ctx->remaining = atol(lenp);
+/* XXX: Are there any platforms where apr_off_t != long?
+aka: Would it be possible to overflow here? */
+/* XXX: Can we get here with an invalid number? (ie <0) */
 }
 }
 }
 
-if (!ctx->remaining)
+if (ctx->remaining <= 0)
 {
 switch (ctx->state)
 {
 case BODY_NONE:
 break;
 case BODY_LENGTH:
+/* We've already consumed the Content-length size, so flush. */
 e = apr_bucket_eos_create();
 APR_BRIGADE_INSERT_TAIL(b, e);
 return APR_SUCCESS;
 case BODY_CHUNK:
+/* Done with this chunk, go get the next chunk length. */
 {
 char line[30];
 
@@ -560,8 +567,7 @@
 ctx->state = BODY_CHUNK;
 ctx->remaining = get_chunk_size(line);
 
-if (!ctx->remaining)
-{
+if (ctx->remaining <= 0) {
 /* Handle trailers by calling get_mime_headers again! */
 e = apr_bucket_eos_create();
 APR_BRIGADE_INSERT_TAIL(b, e);
@@ -572,13 +578,13 @@
 }
 }
 
-rv = ap_get_brigade(f->next, b, mode, readbytes);
-
-if (rv != APR_SUCCESS)
+if ((rv = ap_get_brigade(f->next, b, mode, readbytes)) != APR_SUCCESS) {
 return rv;
+}
 
-if (ctx->state != BODY_NONE)
+if (ctx->state != BODY_NONE) {
 ctx->remaining -= *readbytes;
+}
 
 return APR_SUCCESS;
 }
@@ -1360,19 +1366,17 @@
 &core_module);
 apr_bucket_brigade *bb = req_cfg->bb;
 
-do {
-if (APR_BRIGADE_EMPTY(bb)) {
-if (ap_get_brigade(r->input_filters, bb, AP_MODE_BLOCKING,
-   &r->remaining) != APR_SUCCESS) {
-/* if we actually fail here, we want to just return and
- * stop trying to read data from the client.
- */
-r->connection->keepalive = -1;
-apr_brigade_destroy(bb);
-return -1;
-}
+while (APR_BRIGADE_EMPTY(bb)) {
+if (ap_get_brigade(r->input_filters, bb, AP_MODE_BLOCKING,
+   &r->remaining) != APR_SUCCESS) {
+/* if we actually fail here, we want to just return and
+ * stop trying to read data from the client.
+ */
+r->connection->keepalive = -1;
+apr_brigade_destroy(bb);
+return -1;
 }
-} while (APR_BRIGADE_EMPTY(bb));
+}
 
 b = APR_BRIGADE_FIRST(bb);
 if (APR_BUCKET_IS_EOS(b)) { /* reached eos on previous invocation */

Re: [PATCH] Remove the Port directive.

[Justin Erenkrantz]

On Thu, Oct 04, 2001 at 11:38:30AM -0700, Ryan Bloom wrote:
> It should already support that.  The @@Port@@ in the httpd-std.conf
> is what does that.

Correct me if I'm wrong, but your patch has:

-# Port: The port to which the standalone server listens. For
-# ports < 1023, you will need httpd to be run as root initially.
-#
-Port @@Port@@

What I'm suggesting is adding:

Listen @@Port@@

I sort of agree with Aaron about run-time configuration options, but
not enough that I want to edit files manually.  =)

This concept has always been a topic of debate between Aaron and
myself - we talked about this for a long time when we did flood.
I'd be curious to see what other people think.

I think build-time options can specify the defaults - they can
always be overriden later...  -- justin

Re: [PATCH] Remove the Port directive.

[Ryan Bloom]

On Thursday 04 October 2001 10:33 am, Justin Erenkrantz wrote:
> On Wed, Oct 03, 2001 at 08:24:04PM -0700, Ryan Bloom wrote:
> > This patch completely deprectates the Port directive.  The ServerName
> > directive is now overloaded, so that admins specify the port and name on
> > the same directive.  It also makes Listen a required directive.  Pay
> > attention to that.  There are no default ports with this patch.  If your
> > config doesn't have a Listen directive, the server doesn't start, and it
> > emits an error.
> >
> > I am a bit hesitant to commit this without some feedback, because it is a
> > pretty major change.  Before I commit this, I will update all of the
> > docs.
> >
> > Thoughts?
>
> I'd *like* to see ./configure --with-port=8080 set Listen 8080 in
> httpd.conf.  I don't like seeing the default configuration requiring
> manual edits.  -- justin

It should already support that.  The @@Port@@ in the httpd-std.conf
is what does that.

Ryan

__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: [PATCH] Remove the Port directive.

[Aaron Bannert]

On Thu, Oct 04, 2001 at 10:33:08AM -0700, Justin Erenkrantz wrote:
> I'd *like* to see ./configure --with-port=8080 set Listen 8080 in
> httpd.conf.  I don't like seeing the default configuration requiring
> manual edits.  -- justin

That might cause more trouble for administrators than it's worth, and
for some subtle reasons. Almost all installations will require some
sort of manual intervention, which usually means editing the httpd.conf
file. When people come to depend on a build-time configuration script
to define some of these parameters, they will be less likely to know how
to do it by hand, the end result of which is more users asking for help.

I'm not directing this to you in specific, but I think it may do us well
to separate the build-time configuration from the run-time configuration.

Here's a section from the Autoconf manual titled _Configuring Site Details_:

"Some software packages require complex site-specific information. Some
examples are host names to use for certain services, company names, and
email addresses to contact. Since some configuration scripts generated
by Metaconfig ask for such information interactively, people sometimes
wonder how to get that information in Autoconf-generated configuration
scripts, which aren't interactive."

Instead of having a --with-port parameter at build-time, perhaps our default
configuration should simply have a "Listen 80" directive. If the server can't
bind to port 80, it will be very obvious to the administrator how to fix it,
and they won't try to recomple.

-aaron

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

['[EMAIL PROTECTED]']

On Thu, Oct 04, 2001 at 02:06:04PM -0400, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) 
wrote:
> Justin,
>   While you're working on cleaning up the input filter logic, can you
> also please clean up the variable names / function names used - OtherBill
> had brought up this issue long time back, but it got postponed as we were
> trying to stablize the filtering logic.. Incase you've lotsa other work, i
> can send a patch..

Oh, you bet your bippie, all of the local variables are getting changed
in the filter code (style changes be damned).  =)  I'm also planning on 
switching the style of the filter to match our "typical" filter code -
this will make it easier to understand, hopefully.

FWIW, I'm planning on implementing it like so:

if it is readbytes==0 (getline behavior), 
read a chunk of data via ap_get_brigade
decrypt it
search for LF
if match
setaside remainder into local context.
return the brigade
repeat until we find LF
if it is readbytes!=0,
call ap_get_brigade for that amount of data.
decrypt the brigade.
return the brigade. 
(Note that I think we may end up returning less than is requested
 oftentimes, but that is definitely be permitted in our architecture - 
 just never return more than we ask for...)
   
I don't think we should support readbytes==-1 or peek just yet.

The only thing this means is that SSL_IN can be added at any point,
but it can't be removed once it has been added (since it will have
some buffering).  I don't think that'll be a problem though - I
know you can Upgrade a request to SSL, but I don't think you can
downgrade a request.  If that is the case, we need to think this
over some more...
 
I have class at 2PM, so I hope I can get something working out 
before I need to go to class...  -- justin

Re: [PATCH] [Resubmit] Re: Tagging 1.3.21 now

[Bill Stoddard]

> 
> On Thu, 4 Oct 2001, Bill Stoddard wrote:
> 
> > Committed and tag moved to pick up the change in 1.3.21
> 
> Do you really really want to do this ?
> 
Yes. See my earlier note on the topic.

Bill

Re: [PATCH] [Resubmit] Re: Tagging 1.3.21 now

[Dirk-Willem van Gulik]

On Thu, 4 Oct 2001, Bill Stoddard wrote:

> Committed and tag moved to pick up the change in 1.3.21

Do you really really want to do this ?

In the past those sort of last minute changes have proven to cause endless
havoc - and it was easier to just skip a version number.

Dw

Re: [PATCH] Remove the Port directive.

[Rodent of Unusual Size]

Justin Erenkrantz wrote:
> 
> I'd *like* to see ./configure --with-port=8080 set Listen 8080 in
> httpd.conf.  I don't like seeing the default configuration requiring
> manual edits.  -- justin

+1
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [PATCH] Remove the Port directive.

[Justin Erenkrantz]

On Wed, Oct 03, 2001 at 08:24:04PM -0700, Ryan Bloom wrote:
> 
> This patch completely deprectates the Port directive.  The ServerName
> directive is now overloaded, so that admins specify the port and name on
> the same directive.  It also makes Listen a required directive.  Pay attention
> to that.  There are no default ports with this patch.  If your config doesn't have
> a Listen directive, the server doesn't start, and it emits an error.
> 
> I am a bit hesitant to commit this without some feedback, because it is a pretty
> major change.  Before I commit this, I will update all of the docs.
> 
> Thoughts?

I'd *like* to see ./configure --with-port=8080 set Listen 8080 in
httpd.conf.  I don't like seeing the default configuration requiring
manual edits.  -- justin

Re: [PATCH] [Resubmit] Re: Tagging 1.3.21 now

[Bill Stoddard]

Committed and tag moved to pick up the change in 1.3.21

Bill

- Original Message - 
From: "Sander Temme" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 04, 2001 12:18 PM
Subject: [PATCH] [Resubmit] Re: Tagging 1.3.21 now


> on 10/4/01 6:47 AM, Bill Stoddard at [EMAIL PROTECTED] wrote:
> 
> > Tagged. Please test APACHE_1_3_21 tag. Plan to roll the tarball in 24 hours.
> 
> Fails to compile on Darwin 1.4:
> 
> [monalisa:~/projects/apache-tag] sctemme% uname -a
> Darwin MonaLisa 1.4 Darwin Kernel Version 1.4: Sun Sep  9 15:39:59 PDT 2001;
> root:xnu/xnu-201.obj~1/RELEASE_PPC  Power Macintosh powerpc
> 
> Using config.status from my regular working copy:
> 
> ./configure \
> "--with-layout=Apache" \
> "--prefix=/tmp/apache" \
> "--enable-module=all" \
> "--enable-shared=max" \
> "$@"
> 
> Ends in tears:
> 
> ===> src/modules/experimental
> cc -c  -I../../os/unix -I../../include   -DDARWIN -DUSE_HSREGEX -DUSE_EXPAT
> -I../../lib/expat-lite `../../apaci` -DSHARED_MODULE mod_mmap_static.c && mv
> mod_mmap_static.o mod_mmap_static.lo
> cc  -bundle -undefined suppress -o mod_mmap_static.so mod_mmap_static.lo
> /usr/bin/ld: -undefined error must be used when -twolevel_namespace is in
> effect
> make[4]: *** [mod_mmap_static.so] Error 1
> make[3]: *** [all] Error 1
> make[2]: *** [subdirs] Error 1
> make[2]: Leaving directory `/Users/sctemme/projects/apache-tag/src'
> make[1]: *** [build-std] Error 2
> make[1]: Leaving directory `/Users/sctemme/projects/apache-tag'
> make: *** [build] Error 2
> 
> Patch attached, tested on above and:
> 
> [bistromath:apache_1_3_21] sctemme$uname -a
> FreeBSD bistromath.workbench.covalent.net 4.1-RELEASE FreeBSD 4.1-RELEASE
> #2: Wed Apr 18 12:22:46 PDT 2001
> [EMAIL PROTECTED]:/usr/src/sys/compile/BISTROMATH
> i386
> 
> 
> and:
> 
> [batmobile:sctemme] sctemme$uname -a
> Darwin batmobile 1.3.7 Darwin Kernel Version 1.3.7: Sat Jun  9 11:12:48 PDT
> 2001; root:xnu/xnu-124.13.obj~1/RELEASE_PPC  Power Macintosh powerpc
> 
> Enjoy,
> 
> S.
> 
> -- 
> Covalent Technologies [EMAIL PROTECTED]
> Engineering groupVoice: (415) 536 5214
> 645 Howard St. Fax: (415) 536 5210
> San Francisco CA 94105
> 
>PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03  5531 AFB1 96AF B584 0AB1
> 
> ===
> This email message is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. Any unauthorized review,
> use, disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message
> ===
> 
> 

Re: Tagging 1.3.21 now

[Dirk-Willem van Gulik]

Actually; if you check out (or move) the three into it's position
within the apache tree then you can tag and handle them as 'one'.

Dw

On Thu, 4 Oct 2001, Bill Stoddard wrote:

> My first inclination is to tag httpd-docs-1.3 separately from the rest of the tree. 
>Wanted
> to query the list to see if that is the 'right' solution.
>
> Bill
>
> - Original Message -
> From: "Bill Stoddard" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, October 04, 2001 9:18 AM
> Subject: Re: Tagging 1.3.21 now
>
>
> > I am not able to tag the tree. I get the folliwing messages...
> >
> > Any suggestions?
> >
> >
> > $ cvs tag APACHE_1_3_21
> > cvs server: nothing known about index.html.el
> > cvs server: nothing known about index.html.nn
> > cvs server: nothing known about index.html.zh.Big5
> > cvs server: nothing known about bind.html.en
> > cvs server: nothing known about bind.html.fr
> > cvs server: nothing known about bind.html.html
> > cvs server: nothing known about cgi_path.html.en
> > cvs server: nothing known about cgi_path.html.fr
> > cvs server: nothing known about cgi_path.html.html
> > cvs server: nothing known about configuring.html.en
> > cvs server: nothing known about configuring.html.fr
> > cvs server: nothing known about configuring.html.html
> > cvs server: nothing known about configuring.html.ja.jis
> > cvs server: nothing known about custom-error.html.en
> > cvs server: nothing known about custom-error.html.fr
> > cvs server: nothing known about custom-error.html.html
> > cvs server: nothing known about custom-error.html.ja.jis
> > cvs server: nothing known about cygwin.html
> > cvs server: nothing known about dns-caveats.html.en
> > cvs server: nothing known about dns-caveats.html.fr
> > cvs server: nothing known about dns-caveats.html.html
> > cvs server: nothing known about env.html.en
> > cvs server: nothing known about env.html.html
> > cvs server: nothing known about env.html.ja.jis
> > cvs server: nothing known about handler.html.en
> > cvs server: nothing known about handler.html.html
> > cvs server: nothing known about handler.html.ja.jis
> > cvs server: nothing known about index.html.en
> > cvs server: nothing known about index.html.fr
> > cvs server: nothing known about index.html.html
> > cvs server: nothing known about index.html.ja.jis
> > cvs server: nothing known about install.html.en
> > cvs server: nothing known about install.html.es
> > cvs server: nothing known about install.html.fr
> > cvs server: nothing known about install.html.html
> > cvs server: nothing known about install.html.ja.jis
> > cvs server: nothing known about invoking.html.en
> > cvs server: nothing known about invoking.html.fr
> > cvs server: nothing known about invoking.html.html
> > cvs server: nothing known about keepalive.html.en
> > cvs server: nothing known about keepalive.html.html
> > cvs server: nothing known about keepalive.html.ja.jis
> > cvs server: nothing known about logs.html
> > cvs server: nothing known about mpeix.html
> > cvs server: nothing known about new_features_1_3.html.en
> > cvs server: nothing known about new_features_1_3.html.html
> > cvs server: nothing known about new_features_1_3.html.ja.jis
> > cvs server: nothing known about new_features_2_0.html
> > cvs server: nothing known about server-wide.html.en
> > cvs server: nothing known about server-wide.html.fr
> > cvs server: nothing known about server-wide.html.html
> > cvs server: nothing known about server-wide.html.ja.jis
> > cvs server: nothing known about stopping.html.en
> > cvs server: nothing known about stopping.html.fr
> > cvs server: nothing known about stopping.html.html
> > cvs server: nothing known about suexec.html.en
> > cvs server: nothing known about suexec.html.html
> > cvs server: nothing known about suexec.html.ja.jis
> > cvs server: nothing known about urlmapping.html
> > cvs server: nothing known about win_service.html.en
> > cvs server: nothing known about win_service.html.html
> > cvs server: nothing known about win_service.html.ja.jis
> > cvs server: nothing known about apache_header.gif
> > cvs server: nothing known about pixel.gif
> > cvs server: nothing known about tutorials.html
> > cvs server: nothing known about core.html.en
> > cvs server: nothing known about core.html.fr
> > cvs server: nothing known about core.html.html
> > cvs server: nothing known about directive-dict.html.en
> > cvs server: nothing known about directive-dict.html.fr
> > cvs server: nothing known about directive-dict.html.html
> > cvs server: nothing known about directive-dict.html.ja.jis
> > cvs server: nothing known about directives.html.de
> > cvs server: nothing known about directives.html.en
> > cvs server: nothing known about directives.html.fr
> > cvs server: nothing known about directives.html.html
> > cvs server: nothing known about directives.html.ja.jis
> > cvs server: nothing known about index-bytype.html.en
> > cvs server: nothing known about index-bytype.html.fr
> > cvs server: nothing known

Re: [PATCH] Remove the Port directive.

[Ryan Bloom]

On Thursday 04 October 2001 09:18 am, William A. Rowe, Jr. wrote:
> From: "Aaron Bannert" <[EMAIL PROTECTED]>
> Sent: Thursday, October 04, 2001 11:04 AM
>
> > On Thu, Oct 04, 2001 at 11:50:27AM -0400, Rodent of Unusual Size wrote:
> > > > ServerName this.host.com   [assumes the default port 80]
> > >
> > > except that Ryan said there is no default port any more.
> >
> > There is no default Listener anymore, but if you omit the port from
> > the ServerName directive, it will default to port 80.
>
> There isn't anything that says we can't substitute
>
> Listen 0.0.0.0:80
>
> in the absense of _any_ Listen directives.  This might be more intuitive.

We could do this, but I am afraid it might lead to the same situation we
are in now.  Namely, users saying:

I just added Listen 443 to my config file, and now it stops listening to port 80.

This isn't the only required directive we have, so I don't think it hurts to
not have a default, and just require a Listen directive.

> Speaking of which, would it be good to make a seperate proxy.conf and
> (within subprojects) pop.conf, mbox.conf etc?  I mention it because proxy,
> in particular, adds alot of information to the httpd.conf that some users
> never need to review.  It seems like it would 'lighten the load'.  Of
> course, the same logic as ssl;
>
> 
> Include proxy.conf
> 
>
> would be standard in httpd.conf, just as we suggest for ssl.

++1.

Ryan
__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: [PATCH] Remove the Port directive.

[Ryan Bloom]

On Thursday 04 October 2001 09:14 am, William A. Rowe, Jr. wrote:
> From: "Ryan Bloom" <[EMAIL PROTECTED]>
> Sent: Thursday, October 04, 2001 11:04 AM
>
> > On Thursday 04 October 2001 08:50 am, Rodent of Unusual Size wrote:
> > > "William A. Rowe, Jr." wrote:
> > >
> > > Also, from your example:
> > > > ServerName this.host.com   [assumes the default port 80]
> > >
> > > except that Ryan said there is no default port any more.
> >
> > That was a poor explanation on my part.  The default port is 80, but we
> > do not default a listening port anymore.  This means that we will report
> > that we are listening on port 80 by default, but if there are no Listen
> > directives, the server will not start.
>
> What does this do?
>
> Listen 10.0.0.10
>
> Will it assume a default of :80, or error out?

It errors out saying that a port must be specified.  I didn't change that logic
at all.

Ryan

__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

[PATCH] [Resubmit] Re: Tagging 1.3.21 now

[Sander Temme]

on 10/4/01 6:47 AM, Bill Stoddard at [EMAIL PROTECTED] wrote:

> Tagged. Please test APACHE_1_3_21 tag. Plan to roll the tarball in 24 hours.

Fails to compile on Darwin 1.4:

[monalisa:~/projects/apache-tag] sctemme% uname -a
Darwin MonaLisa 1.4 Darwin Kernel Version 1.4: Sun Sep  9 15:39:59 PDT 2001;
root:xnu/xnu-201.obj~1/RELEASE_PPC  Power Macintosh powerpc

Using config.status from my regular working copy:

./configure \
"--with-layout=Apache" \
"--prefix=/tmp/apache" \
"--enable-module=all" \
"--enable-shared=max" \
"$@"

Ends in tears:

===> src/modules/experimental
cc -c  -I../../os/unix -I../../include   -DDARWIN -DUSE_HSREGEX -DUSE_EXPAT
-I../../lib/expat-lite `../../apaci` -DSHARED_MODULE mod_mmap_static.c && mv
mod_mmap_static.o mod_mmap_static.lo
cc  -bundle -undefined suppress -o mod_mmap_static.so mod_mmap_static.lo
/usr/bin/ld: -undefined error must be used when -twolevel_namespace is in
effect
make[4]: *** [mod_mmap_static.so] Error 1
make[3]: *** [all] Error 1
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/Users/sctemme/projects/apache-tag/src'
make[1]: *** [build-std] Error 2
make[1]: Leaving directory `/Users/sctemme/projects/apache-tag'
make: *** [build] Error 2

Patch attached, tested on above and:

[bistromath:apache_1_3_21] sctemme$uname -a
FreeBSD bistromath.workbench.covalent.net 4.1-RELEASE FreeBSD 4.1-RELEASE
#2: Wed Apr 18 12:22:46 PDT 2001
[EMAIL PROTECTED]:/usr/src/sys/compile/BISTROMATH
i386


and:

[batmobile:sctemme] sctemme$uname -a
Darwin batmobile 1.3.7 Darwin Kernel Version 1.3.7: Sat Jun  9 11:12:48 PDT
2001; root:xnu/xnu-124.13.obj~1/RELEASE_PPC  Power Macintosh powerpc

Enjoy,

S.

-- 
Covalent Technologies [EMAIL PROTECTED]
Engineering groupVoice: (415) 536 5214
645 Howard St. Fax: (415) 536 5210
San Francisco CA 94105

   PGP Fingerprint: 1E74 4E58 DFAC 2CF5 6A03  5531 AFB1 96AF B584 0AB1

===
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message
===



Index: src/Configure
===
RCS file: /home/cvspublic/apache-1.3/src/Configure,v
retrieving revision 1.433
diff -u -r1.433 Configure
--- src/Configure   2001/10/03 12:59:03 1.433
+++ src/Configure   2001/10/04 15:47:35
@@ -1149,7 +1149,14 @@
*-apple-rhapsody* | *-apple-darwin* )
LD_SHLIB="cc"
CFLAGS_SHLIB=""
-   LDFLAGS_SHLIB='$(EXTRA_LDFLAGS) -bundle -undefined suppress'
+   case "$PLAT" in
+   *-apple-darwin1.4 )
+   LDFLAGS_SHLIB='$(EXTRA_LDFLAGS) -bundle -undefined suppress 
+-flat_namespace'
+   ;;
+   * )
+   LDFLAGS_SHLIB='$(EXTRA_LDFLAGS) -bundle -undefined suppress'
+   ;;
+   esac
LDFLAGS_MOD_SHLIB=$LDFLAGS_SHLIB
LDFLAGS_SHLIB_EXPORT=""
SHLIB_SUFFIX_DEPTH=0

Re: [PATCH] Remove the Port directive.

[William A. Rowe, Jr.]

From: "Aaron Bannert" <[EMAIL PROTECTED]>
Sent: Thursday, October 04, 2001 11:04 AM


> On Thu, Oct 04, 2001 at 11:50:27AM -0400, Rodent of Unusual Size wrote:
> > > ServerName this.host.com   [assumes the default port 80]
> > 
> > except that Ryan said there is no default port any more.
> 
> There is no default Listener anymore, but if you omit the port from
> the ServerName directive, it will default to port 80.

There isn't anything that says we can't substitute

Listen 0.0.0.0:80

in the absense of _any_ Listen directives.  This might be more intuitive.

Of course, that doesn't lessen the need for the Listen 80 in our default
config!  If we don't provide that directive, and the user adds in the ssl
or pop config, then we are in _serious_ trouble.

Speaking of which, would it be good to make a seperate proxy.conf and
(within subprojects) pop.conf, mbox.conf etc?  I mention it because proxy,
in particular, adds alot of information to the httpd.conf that some users
never need to review.  It seems like it would 'lighten the load'.  Of course,
the same logic as ssl;


Include proxy.conf


would be standard in httpd.conf, just as we suggest for ssl.

Bill

Re: [PATCH] Remove the Port directive.

[William A. Rowe, Jr.]

From: "Ryan Bloom" <[EMAIL PROTECTED]>
Sent: Thursday, October 04, 2001 11:04 AM


> On Thursday 04 October 2001 08:50 am, Rodent of Unusual Size wrote:
> > "William A. Rowe, Jr." wrote:
> 
> > Also, from your example:
> > > ServerName this.host.com   [assumes the default port 80]
> >
> > except that Ryan said there is no default port any more.
> 
> That was a poor explanation on my part.  The default port is 80, but we
> do not default a listening port anymore.  This means that we will report that
> we are listening on port 80 by default, but if there are no Listen directives,
> the server will not start.

What does this do?

Listen 10.0.0.10

Will it assume a default of :80, or error out?

Re: [PATCH] Remove the Port directive.

[Aaron Bannert]

On Thu, Oct 04, 2001 at 11:50:27AM -0400, Rodent of Unusual Size wrote:
> > ServerName this.host.com   [assumes the default port 80]
> 
> except that Ryan said there is no default port any more.

There is no default Listener anymore, but if you omit the port from
the ServerName directive, it will default to port 80.

-aaron

Re: [PATCH] Remove the Port directive.

[Ryan Bloom]

On Thursday 04 October 2001 08:50 am, Rodent of Unusual Size wrote:
> "William A. Rowe, Jr." wrote:
> > And if you are correct, that this breaks VirtualHost, then
> > we have a bug and we better fix that before Ryan's commit.
>
> I am not sure if it breaks it or not, but having lots of
> flexibility for specifying name/address/port in the 
> open directive bungs up the cleanliness.
>
> Listen 80
> ServerName Foo.Com
> 
>
> What happens?  Presumably the vhost will never hear anything,
> but will/should we detect it and report it?

We don't today.  Should we, probably.  This patch does not touch this
logic though.

> Also, from your example:
> > ServerName this.host.com   [assumes the default port 80]
>
> except that Ryan said there is no default port any more.

That was a poor explanation on my part.  The default port is 80, but we
do not default a listening port anymore.  This means that we will report that
we are listening on port 80 by default, but if there are no Listen directives,
the server will not start.

Ryan
__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: [PATCH] Remove the Port directive.

[Cliff Woolley]

On Thu, 4 Oct 2001, Rodent of Unusual Size wrote:

> > ServerName this.host.com   [assumes the default port 80]
>
> except that Ryan said there is no default port any more.

He said there is no default _listener_.

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA

Re: [PATCH] Remove the Port directive.

[Aaron Bannert]

On Thu, Oct 04, 2001 at 06:36:18AM -0700, Ryan Bloom wrote:
> On Wednesday 03 October 2001 08:36 pm, Aaron Bannert wrote:
> > On Wed, Oct 03, 2001 at 08:35:04PM -0700, Ryan Bloom wrote:
> > > The thing that concerns me the most, is that there is no default Port. 
> > > If people can accept that change, then I think this is the right way to
> > > go.
> >
> > I think you meant there is no default listener.
> >
> > So what happens with this patch if you don't specify a listener?
> 
> As I said in the original message, it doesn't start the server, and an error
> is written to the error log.

Missed that.

BTW, I am ++1 on this (FWIW). It clears up a longstanding point of confusion.

-aaron

Re: Tagging 1.3.21 now

[Rodent of Unusual Size]

Bill Stoddard wrote:
> 
> Good message from Mark that is worthy of discussion...

I think there's one tweak needed in mod_auth.c..
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [PATCH] Remove the Port directive.

[Rodent of Unusual Size]

"William A. Rowe, Jr." wrote:
> 
> Now our users have exactly _two_ directives to comprehend:
> 
> Listen controls what addresses and ports the server listens on;
> 
> ServerName defines the server's OWN name for itself, including
> it's port if it is a nonstandard assignment;

All right, got it.  

> And if you are correct, that this breaks VirtualHost, then
> we have a bug and we better fix that before Ryan's commit.

I am not sure if it breaks it or not, but having lots of
flexibility for specifying name/address/port in the 
open directive bungs up the cleanliness.

Listen 80
ServerName Foo.Com


What happens?  Presumably the vhost will never hear anything,
but will/should we detect it and report it?

Also, from your example:

> ServerName this.host.com   [assumes the default port 80]

except that Ryan said there is no default port any more.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Configure for 1.3.21 is semi-"broken"

[Jim Jagielski]

Just saw this in Configure after Cliff's note (which is resolved):


## Add in the Expat library if needed/wanted.
##

# set the default, based on whether expat-lite is bundled. if it is present,
# then we can always include expat.
if [ "x$RULE_EXPAT" = "xdefault" ]; then
if [ -d ./lib/expat-lite/ ]; then
RULE_EXPAT=yes
else
RULE_EXPAT=no
fi
fi

if [ "x$RULE_EXPAT" = "xyes" ]; then
if ./helpers/TestCompile lib expat; then
echo " + using system Expat"
LIBS="$LIBS -lexpat"
else
if [ "$xRULE_EXPAT" = "xyes" ]; then

echo "ERROR: RULE_EXPAT set to \"yes\" but is not available."
exit 1
fi
echo " + using builtin Expat"
EXPATLIB="lib/expat-lite/libexpat.a"
APLIBDIRS="expat-lite $APLIBDIRS"
CFLAGS="$CFLAGS -DUSE_EXPAT -I\$(SRCDIR)/lib/expat-lite"
fi
fi

Note the line above the ''. Luckily, this section still works
as required (lucky typo)... But there's a mismatch of logic here, regarding
what the EXPAT rule really means... Right now, if there's a system
expat lib, it will *always* be chosen, and there's no way to bypass
that. Up to now, I think we've always been using expat-lite... Because
of this, it's pretty important that we test out 1.3.21 as well as
possible, especially with those platforms that provide expat. I
don't think there's a need to hold off on 1.3.21 at present though.

Sorry I didn't notice this sooner... After the dust settles I'll
adjust this section to deal with the new logic.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

Re: Tagging 1.3.21 now

[Jim Jagielski]

Yeah, normally a tarball is done right after the tagging... so the
tarball tested is the the one that is actually distributed, assuming
all works out OK.

Bill Stoddard wrote:
> 
> Good message from Mark that is worthy of discussion...
> 
> 
> - Original Message -
> From: "Mark J Cox" <[EMAIL PROTECTED]>
> To: "Bill Stoddard" <[EMAIL PROTECTED]>
> Sent: Thursday, October 04, 2001 11:03 AM
> Subject: Re: Tagging 1.3.21 now
> 
> 
> > Bill; normally the RM releases a tarball at this stage, so we can test the
> > whole package (which might be missing files etc).  Otherwise anyone
> > wanting to test has to pull the tree with the right tag and go through the
> > release process to get a kosher tarball.  (there is supposed to be 24
> > hours between the release of the tarball on dev.apache.org for testing,
> > and the real public release)
> >
> > Cheers,
> > Mark
> >
> 
> Yes I understand. I am adopting a process tweak that seems to work well for Apache 
>2.0.
> People can extract APACHE_1_3_21 to test the obvious things like "will the server
> compile".  If we have minor breakage that can easily be fixed, we make the changes 
>and
> bump the tag.  I put an arbitrary time limit of 24 hours on this phase of the T&R 
>process.
> 
> At the end of 24 hours, we either abandon the tag (because there were just too many
> problems) or roll the tarball and start the tarball test cycle.
> 
> I believe this process results in a slightly reduced workload for the RM (in the 
>cases
> where the TAG had to be abandonded). Also, missed version numbers look bad to the 
>user
> community and invariably generates questions like (was 1.3.blah ever released? why 
>not?
> yadda yadda yadda).
> 
> Bill
> 


-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

false alarm Re: problem building 1.3.21 on linux

[Cliff Woolley]

On Thu, 4 Oct 2001, Jim Jagielski wrote:

> >  + using system Expat
> > ./gen_test_char >test_char.h
> > ./gen_test_char: error while loading shared libraries: cannot open shared
> > object file: cannot load shared object file: No such file or directory
>
> Ugg. I'm thinking that this may be due to an Expat change that was
> recently made to Configure (IIRC). That sort of thing should have been
> caught in the compiler sanity check phase...

Whooopps, my fault.  False alarm.  I do have Expat installed
(/usr/local/lib), but I forgot to rerun ldconfig after I installed it.  I
just did so and then make clean ; make and all is well.

Phew!  :)

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA

Re: problem building 1.3.21 on linux

[Jim Jagielski]

Jim Jagielski wrote:
> 
> Ugg. I'm thinking that this may be due to an Expat change that was
> recently made to Configure (IIRC). That sort of thing should have been
> caught in the compiler sanity check phase...
> 

Hmmm... At the very least, there's a typo in Configure during the
EXPAT stuff which ain't right :)

I would expect that up to now, Slackware's been using our
expat-lite and not it's system libexpat.a file. Most likely,
there's some dependencies with your expat lib that we aren't
picking up.

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

Re: Tagging 1.3.21 now

[Bill Stoddard]

Good message from Mark that is worthy of discussion...


- Original Message -
From: "Mark J Cox" <[EMAIL PROTECTED]>
To: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Thursday, October 04, 2001 11:03 AM
Subject: Re: Tagging 1.3.21 now


> Bill; normally the RM releases a tarball at this stage, so we can test the
> whole package (which might be missing files etc).  Otherwise anyone
> wanting to test has to pull the tree with the right tag and go through the
> release process to get a kosher tarball.  (there is supposed to be 24
> hours between the release of the tarball on dev.apache.org for testing,
> and the real public release)
>
> Cheers,
> Mark
>

Yes I understand. I am adopting a process tweak that seems to work well for Apache 2.0.
People can extract APACHE_1_3_21 to test the obvious things like "will the server
compile".  If we have minor breakage that can easily be fixed, we make the changes and
bump the tag.  I put an arbitrary time limit of 24 hours on this phase of the T&R 
process.

At the end of 24 hours, we either abandon the tag (because there were just too many
problems) or roll the tarball and start the tarball test cycle.

I believe this process results in a slightly reduced workload for the RM (in the cases
where the TAG had to be abandonded). Also, missed version numbers look bad to the user
community and invariably generates questions like (was 1.3.blah ever released? why not?
yadda yadda yadda).

Bill

Re: problem building 1.3.21 on linux

[Jim Jagielski]

Cliff Woolley wrote:
> 
> Creating Configuration.apaci in src
> Creating Makefile in src
>  + configured for Linux platform
>  + setting C compiler to gcc
>  + setting C pre-processor to gcc -E
>  + checking for system header files
>  + adding selected modules
>  + using system Expat
> 
> Then make:
> 
> [snip]
> ===> src/main
> gcc -c  -I../os/unix -I../include   -DLINUX=22 -DUSE_HSREGEX
> -DNO_DL_NEEDED `../apaci` gen_test_char.c
> gcc  -DLINUX=22 -DUSE_HSREGEX -DNO_DL_NEEDED `../apaci`   -o gen_test_char
> gen_test_char.o  -lm -lcrypt -lexpat
> ./gen_test_char >test_char.h
> ./gen_test_char: error while loading shared libraries: cannot open shared
> object file: cannot load shared object file: No such file or directory

Ugg. I'm thinking that this may be due to an Expat change that was
recently made to Configure (IIRC). That sort of thing should have been
caught in the compiler sanity check phase...

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

problem building 1.3.21 on linux

[Cliff Woolley]

I just pulled down 1.3.21 from CVS with the following command:

cvs -d cvs.apache.org:/home/cvs co -r APACHE_1_3_21 -d apache-1.3.21 apache-1.3


And then ran configure like so:

./configure --prefix=/root/test13

Configuring for Apache, Version 1.3.21
 + using installation path layout: Apache (config.layout)
Creating Makefile
Creating Configuration.apaci in src
Creating Makefile in src
 + configured for Linux platform
 + setting C compiler to gcc
 + setting C pre-processor to gcc -E
 + checking for system header files
 + adding selected modules
 + using system Expat
 + checking sizeof various data types
 + doing sanity check on compiler and options
Creating Makefile in src/support
Creating Makefile in src/regex
Creating Makefile in src/os/unix
Creating Makefile in src/ap
Creating Makefile in src/main
Creating Makefile in src/modules/standard


Then make:

[snip]
===> src/main
gcc -c  -I../os/unix -I../include   -DLINUX=22 -DUSE_HSREGEX
-DNO_DL_NEEDED `../apaci` gen_test_char.c
gcc  -DLINUX=22 -DUSE_HSREGEX -DNO_DL_NEEDED `../apaci`   -o gen_test_char
gen_test_char.o  -lm -lcrypt -lexpat
./gen_test_char >test_char.h
./gen_test_char: error while loading shared libraries: cannot open shared
object file: cannot load shared object file: No such file or directory
make[3]: *** [test_char.h] Error 127
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/root/apache/apache-1.3.21/src'
make[1]: *** [build-std] Error 2
make[1]: Leaving directory `/root/apache/apache-1.3.21'
make: *** [build] Error 2


This is on Slackware 8.0.  Have I missed an important step or is it
something broken with my system or is it a problem in the tag?

--Cliff

--
   Cliff Woolley
   [EMAIL PROTECTED]
   Charlottesville, VA

Re: Tagging 1.3.21 now

[Jim Jagielski]

David McCreedy wrote:
> 
> 
> Stupid question... where do I pull APACHE_1_3_21 from?
> 
right from CVS:
cvs co -r APACHE_1_3_21 -d apache-1.3.21 apache-1.3

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

Re: cvs commit: apache-1.3/src/main http_main.c

[David McCreedy]

That should be fine... It's one of the options I tested when I was working
up my patch.

Thanks,

-David



   

Jim Jagielski  

<[EMAIL PROTECTED]   To: [EMAIL PROTECTED]  

om>  cc:   

 Subject: Re: cvs commit: 
apache-1.3/src/main http_main.c  
10/04/2001 

06:19 AM   

Please respond 

to dev 

   

   




[EMAIL PROTECTED] wrote:
>
>   -static void accept_mutex_init_tpfcore(pool *foo)
>   -{
>   -}
>   +#define accept_mutex_init_tpfcore(x)
>
>static void accept_mutex_child_init_tpfcore(pool *p)
>{
>   @@ -1100,7 +1098,7 @@
>
>accept_mutex_methods_s accept_mutex_tpfcore_s = {
>accept_mutex_child_init_tpfcore,
>   -accept_mutex_init_tpfcore,
>   +NULL,
>accept_mutex_on_tpfcore,
>accept_mutex_off_tpfcore,
>"tpfcore"
>

Ideally, what I should have done in the 1st place is:

   #define accept_mutex_foo_bar NULL

for those nop's that way we would have avoided the above, and all the
structures would be semi-consistant, rather than a mix of real
functions and NULLs... I never documented that those mutex functions that
were null defines mapped to NULL entries in the struct... Worth holding
off 1.3.21 for this??

--
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

Re: Tagging 1.3.21 now

[David McCreedy]

Stupid question... where do I pull APACHE_1_3_21 from?

-David



   

"Bill  

Stoddard"To: <[EMAIL PROTECTED]>

   Subject: Re: Tagging 1.3.21 now   

   

10/04/2001 

07:47 AM   

Please respond 

to dev 

   

   




Tagged. Please test APACHE_1_3_21 tag. Plan to roll the tarball in 24
hours.

Bill

> Hold on commits.
>
> Bill,
> Let's save the usertrack patch for 1.3.22. I did a bit of
testing/compiling last night
and
> I would prefer not to redo that work.
>
>
> Bill
>

Re: [PATCH] Remove the Port directive.

[Ryan Bloom]

On Thursday 04 October 2001 04:30 am, Rodent of Unusual Size wrote:
> Cliff Woolley wrote:
> > +1.  Port vs. Listen has always been one of the things
> > people just can't seem to figure out no matter how
> > carefully we try to explain it.  Doing it through
> > ServerName makes it much more clear what's going on.
>
> Due to the non-1:1 relationship between names and
> addresses, and that ports should be associated with
> IP addresses rather than names, I feel uncomfortable
> with the blanket statement above.

But Port hasn't been about selecting a port to listen to for a long time.
That is what Listen was for.  The only reason to have Port (in any situation
where you had multiple ports to listen to), was to have a way to tell the
server what port to report.

This removes the problem of having users put a Port directive in their config,
and two listen directives, and then wonder why the server was only listening
on two ports.  I have received three bug reports about this, this month alone.

Ryan

__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: Tagging 1.3.21 now

[Bill Stoddard]

Tagged. Please test APACHE_1_3_21 tag. Plan to roll the tarball in 24 hours.

Bill

> Hold on commits.
>
> Bill,
> Let's save the usertrack patch for 1.3.22. I did a bit of testing/compiling last 
>night
and
> I would prefer not to redo that work.
>
>
> Bill
>

Re: Tagging 1.3.21 now

[William A. Rowe, Jr.]

From: "Paul Hooper" <[EMAIL PROTECTED]>
Sent: Thursday, October 04, 2001 8:24 AM


> Understand it all bar PITA.  Please fill me in.

"Pain in the Ass"

It didn't need to be this painful, the apache-1.3/htdocs branch could
have been granted group ownership to the apdocs folks, and that would
have been the end of it.  It's been 'undone' (read: fixed) for the 2.0
tree, would be nice to see it fixed here too someday.  There was really
no good reason for a subtree.

The real headache is the document history cached away in the 'real'
htdocs - so they will perpetually clash as Bill noticed.

Bill

> -Original Message-
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
> Sent: 04 October 2001 14:24
> To: [EMAIL PROTECTED]
> Subject: Re: Tagging 1.3.21 now
> 
> 
> Welcome to the doc-split bogosity.
> 
> Did you do a clean checkout with -P?  After you do so, remove the
> htdocs directory, edit your cvs/entries and remove D/htdocs,
> then cvs co -Pd htdocs httpd-docs-1.3/htdocs within your apache1.3
> directory.
> 
> You may now need to cvs tag -F to overcome a partial tag.
> 
> Real PITA that is.
> 
> Bill

Re: [PATCH] Remove the Port directive.

[Ryan Bloom]

On Wednesday 03 October 2001 08:36 pm, Aaron Bannert wrote:
> On Wed, Oct 03, 2001 at 08:35:04PM -0700, Ryan Bloom wrote:
> > The thing that concerns me the most, is that there is no default Port. 
> > If people can accept that change, then I think this is the right way to
> > go.
>
> I think you meant there is no default listener.
>
> So what happens with this patch if you don't specify a listener?

As I said in the original message, it doesn't start the server, and an error
is written to the error log.

Ryan
__
Ryan Bloom  [EMAIL PROTECTED]
Covalent Technologies   [EMAIL PROTECTED]
--

Re: Tagging 1.3.21 now

[Jim Jagielski]

Bill Stoddard wrote:
> 
> I am not able to tag the tree. I get the folliwing messages...
> 
> Any suggestions?
> 

Argf. No doubt this is due to the split of the htdocs tree into it's
own branch. I recall this almost biting me as well last time I tagged.
The trick, IIRC, is to do a checkout of apache-1.3 as well as
the httpd-docs-1.3 tree, but *inside* the apache-1.3 directory
(to populate htdocs). And you only need httpd-docs-1.3/htdocs at that.
Assuming a relatively recent version of cvs, it's smart enough to
handle 2 CVS trees and tag appropriately.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

RE: Tagging 1.3.21 now

[Paul Hooper]

Understand it all bar PITA.  Please fill me in.

-Original Message-
From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
Sent: 04 October 2001 14:24
To: [EMAIL PROTECTED]
Subject: Re: Tagging 1.3.21 now


Welcome to the doc-split bogosity.

Did you do a clean checkout with -P?  After you do so, remove the
htdocs directory, edit your cvs/entries and remove D/htdocs,
then cvs co -Pd htdocs httpd-docs-1.3/htdocs within your apache1.3
directory.

You may now need to cvs tag -F to overcome a partial tag.

Real PITA that is.

Bill



- Original Message - 
From: "Bill Stoddard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 04, 2001 8:18 AM
Subject: Re: Tagging 1.3.21 now


> I am not able to tag the tree. I get the folliwing messages...
> 
> Any suggestions?
> 
> 
> $ cvs tag APACHE_1_3_21
> cvs server: nothing known about index.html.el
> cvs server: nothing known about index.html.nn
> cvs server: nothing known about index.html.zh.Big5
> cvs server: nothing known about bind.html.en
> cvs server: nothing known about bind.html.fr
> cvs server: nothing known about bind.html.html
> cvs server: nothing known about cgi_path.html.en
> cvs server: nothing known about cgi_path.html.fr
> cvs server: nothing known about cgi_path.html.html
> cvs server: nothing known about configuring.html.en
> cvs server: nothing known about configuring.html.fr
> cvs server: nothing known about configuring.html.html
> cvs server: nothing known about configuring.html.ja.jis
> cvs server: nothing known about custom-error.html.en
> cvs server: nothing known about custom-error.html.fr
> cvs server: nothing known about custom-error.html.html
> cvs server: nothing known about custom-error.html.ja.jis
> cvs server: nothing known about cygwin.html
> cvs server: nothing known about dns-caveats.html.en
> cvs server: nothing known about dns-caveats.html.fr
> cvs server: nothing known about dns-caveats.html.html
> cvs server: nothing known about env.html.en
> cvs server: nothing known about env.html.html
> cvs server: nothing known about env.html.ja.jis
> cvs server: nothing known about handler.html.en
> cvs server: nothing known about handler.html.html
> cvs server: nothing known about handler.html.ja.jis
> cvs server: nothing known about index.html.en
> cvs server: nothing known about index.html.fr
> cvs server: nothing known about index.html.html
> cvs server: nothing known about index.html.ja.jis
> cvs server: nothing known about install.html.en
> cvs server: nothing known about install.html.es
> cvs server: nothing known about install.html.fr
> cvs server: nothing known about install.html.html
> cvs server: nothing known about install.html.ja.jis
> cvs server: nothing known about invoking.html.en
> cvs server: nothing known about invoking.html.fr
> cvs server: nothing known about invoking.html.html
> cvs server: nothing known about keepalive.html.en
> cvs server: nothing known about keepalive.html.html
> cvs server: nothing known about keepalive.html.ja.jis
> cvs server: nothing known about logs.html
> cvs server: nothing known about mpeix.html
> cvs server: nothing known about new_features_1_3.html.en
> cvs server: nothing known about new_features_1_3.html.html
> cvs server: nothing known about new_features_1_3.html.ja.jis
> cvs server: nothing known about new_features_2_0.html
> cvs server: nothing known about server-wide.html.en
> cvs server: nothing known about server-wide.html.fr
> cvs server: nothing known about server-wide.html.html
> cvs server: nothing known about server-wide.html.ja.jis
> cvs server: nothing known about stopping.html.en
> cvs server: nothing known about stopping.html.fr
> cvs server: nothing known about stopping.html.html
> cvs server: nothing known about suexec.html.en
> cvs server: nothing known about suexec.html.html
> cvs server: nothing known about suexec.html.ja.jis
> cvs server: nothing known about urlmapping.html
> cvs server: nothing known about win_service.html.en
> cvs server: nothing known about win_service.html.html
> cvs server: nothing known about win_service.html.ja.jis
> cvs server: nothing known about apache_header.gif
> cvs server: nothing known about pixel.gif
> cvs server: nothing known about tutorials.html
> cvs server: nothing known about core.html.en
> cvs server: nothing known about core.html.fr
> cvs server: nothing known about core.html.html
> cvs server: nothing known about directive-dict.html.en
> cvs server: nothing known about directive-dict.html.fr
> cvs server: nothing known about directive-dict.html.html
> cvs server: nothing known about directive-dict.html.ja.jis
> cvs server: nothing known about directives.html.de
> cvs server: nothing known about directives.html.en
> cvs server: nothing known about directives.html.fr
> cvs server: nothing known about directives.html.html
> cvs server: nothing known about directives.html.ja.jis
> cvs server: nothing known about index-bytype.html.en
> cvs server: nothing known about index-bytype.html.fr
> cvs 

Re: Tagging 1.3.21 now

[Bill Stoddard]

My first inclination is to tag httpd-docs-1.3 separately from the rest of the tree. 
Wanted
to query the list to see if that is the 'right' solution.

Bill

- Original Message -
From: "Bill Stoddard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 04, 2001 9:18 AM
Subject: Re: Tagging 1.3.21 now


> I am not able to tag the tree. I get the folliwing messages...
>
> Any suggestions?
>
>
> $ cvs tag APACHE_1_3_21
> cvs server: nothing known about index.html.el
> cvs server: nothing known about index.html.nn
> cvs server: nothing known about index.html.zh.Big5
> cvs server: nothing known about bind.html.en
> cvs server: nothing known about bind.html.fr
> cvs server: nothing known about bind.html.html
> cvs server: nothing known about cgi_path.html.en
> cvs server: nothing known about cgi_path.html.fr
> cvs server: nothing known about cgi_path.html.html
> cvs server: nothing known about configuring.html.en
> cvs server: nothing known about configuring.html.fr
> cvs server: nothing known about configuring.html.html
> cvs server: nothing known about configuring.html.ja.jis
> cvs server: nothing known about custom-error.html.en
> cvs server: nothing known about custom-error.html.fr
> cvs server: nothing known about custom-error.html.html
> cvs server: nothing known about custom-error.html.ja.jis
> cvs server: nothing known about cygwin.html
> cvs server: nothing known about dns-caveats.html.en
> cvs server: nothing known about dns-caveats.html.fr
> cvs server: nothing known about dns-caveats.html.html
> cvs server: nothing known about env.html.en
> cvs server: nothing known about env.html.html
> cvs server: nothing known about env.html.ja.jis
> cvs server: nothing known about handler.html.en
> cvs server: nothing known about handler.html.html
> cvs server: nothing known about handler.html.ja.jis
> cvs server: nothing known about index.html.en
> cvs server: nothing known about index.html.fr
> cvs server: nothing known about index.html.html
> cvs server: nothing known about index.html.ja.jis
> cvs server: nothing known about install.html.en
> cvs server: nothing known about install.html.es
> cvs server: nothing known about install.html.fr
> cvs server: nothing known about install.html.html
> cvs server: nothing known about install.html.ja.jis
> cvs server: nothing known about invoking.html.en
> cvs server: nothing known about invoking.html.fr
> cvs server: nothing known about invoking.html.html
> cvs server: nothing known about keepalive.html.en
> cvs server: nothing known about keepalive.html.html
> cvs server: nothing known about keepalive.html.ja.jis
> cvs server: nothing known about logs.html
> cvs server: nothing known about mpeix.html
> cvs server: nothing known about new_features_1_3.html.en
> cvs server: nothing known about new_features_1_3.html.html
> cvs server: nothing known about new_features_1_3.html.ja.jis
> cvs server: nothing known about new_features_2_0.html
> cvs server: nothing known about server-wide.html.en
> cvs server: nothing known about server-wide.html.fr
> cvs server: nothing known about server-wide.html.html
> cvs server: nothing known about server-wide.html.ja.jis
> cvs server: nothing known about stopping.html.en
> cvs server: nothing known about stopping.html.fr
> cvs server: nothing known about stopping.html.html
> cvs server: nothing known about suexec.html.en
> cvs server: nothing known about suexec.html.html
> cvs server: nothing known about suexec.html.ja.jis
> cvs server: nothing known about urlmapping.html
> cvs server: nothing known about win_service.html.en
> cvs server: nothing known about win_service.html.html
> cvs server: nothing known about win_service.html.ja.jis
> cvs server: nothing known about apache_header.gif
> cvs server: nothing known about pixel.gif
> cvs server: nothing known about tutorials.html
> cvs server: nothing known about core.html.en
> cvs server: nothing known about core.html.fr
> cvs server: nothing known about core.html.html
> cvs server: nothing known about directive-dict.html.en
> cvs server: nothing known about directive-dict.html.fr
> cvs server: nothing known about directive-dict.html.html
> cvs server: nothing known about directive-dict.html.ja.jis
> cvs server: nothing known about directives.html.de
> cvs server: nothing known about directives.html.en
> cvs server: nothing known about directives.html.fr
> cvs server: nothing known about directives.html.html
> cvs server: nothing known about directives.html.ja.jis
> cvs server: nothing known about index-bytype.html.en
> cvs server: nothing known about index-bytype.html.fr
> cvs server: nothing known about index-bytype.html.html
> cvs server: nothing known about index.html.en
> cvs server: nothing known about index.html.fr
> cvs server: nothing known about index.html.html
> cvs server: nothing known about index.html.ja.jis
> cvs server: nothing known about mod_env.html.en
> cvs server: nothing known about mod_env.html.html
> cvs server: nothing known about mod_env.h

Re: Tagging 1.3.21 now

[William A. Rowe, Jr.]

Welcome to the doc-split bogosity.

Did you do a clean checkout with -P?  After you do so, remove the
htdocs directory, edit your cvs/entries and remove D/htdocs,
then cvs co -Pd htdocs httpd-docs-1.3/htdocs within your apache1.3
directory.

You may now need to cvs tag -F to overcome a partial tag.

Real PITA that is.

Bill



- Original Message - 
From: "Bill Stoddard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 04, 2001 8:18 AM
Subject: Re: Tagging 1.3.21 now


> I am not able to tag the tree. I get the folliwing messages...
> 
> Any suggestions?
> 
> 
> $ cvs tag APACHE_1_3_21
> cvs server: nothing known about index.html.el
> cvs server: nothing known about index.html.nn
> cvs server: nothing known about index.html.zh.Big5
> cvs server: nothing known about bind.html.en
> cvs server: nothing known about bind.html.fr
> cvs server: nothing known about bind.html.html
> cvs server: nothing known about cgi_path.html.en
> cvs server: nothing known about cgi_path.html.fr
> cvs server: nothing known about cgi_path.html.html
> cvs server: nothing known about configuring.html.en
> cvs server: nothing known about configuring.html.fr
> cvs server: nothing known about configuring.html.html
> cvs server: nothing known about configuring.html.ja.jis
> cvs server: nothing known about custom-error.html.en
> cvs server: nothing known about custom-error.html.fr
> cvs server: nothing known about custom-error.html.html
> cvs server: nothing known about custom-error.html.ja.jis
> cvs server: nothing known about cygwin.html
> cvs server: nothing known about dns-caveats.html.en
> cvs server: nothing known about dns-caveats.html.fr
> cvs server: nothing known about dns-caveats.html.html
> cvs server: nothing known about env.html.en
> cvs server: nothing known about env.html.html
> cvs server: nothing known about env.html.ja.jis
> cvs server: nothing known about handler.html.en
> cvs server: nothing known about handler.html.html
> cvs server: nothing known about handler.html.ja.jis
> cvs server: nothing known about index.html.en
> cvs server: nothing known about index.html.fr
> cvs server: nothing known about index.html.html
> cvs server: nothing known about index.html.ja.jis
> cvs server: nothing known about install.html.en
> cvs server: nothing known about install.html.es
> cvs server: nothing known about install.html.fr
> cvs server: nothing known about install.html.html
> cvs server: nothing known about install.html.ja.jis
> cvs server: nothing known about invoking.html.en
> cvs server: nothing known about invoking.html.fr
> cvs server: nothing known about invoking.html.html
> cvs server: nothing known about keepalive.html.en
> cvs server: nothing known about keepalive.html.html
> cvs server: nothing known about keepalive.html.ja.jis
> cvs server: nothing known about logs.html
> cvs server: nothing known about mpeix.html
> cvs server: nothing known about new_features_1_3.html.en
> cvs server: nothing known about new_features_1_3.html.html
> cvs server: nothing known about new_features_1_3.html.ja.jis
> cvs server: nothing known about new_features_2_0.html
> cvs server: nothing known about server-wide.html.en
> cvs server: nothing known about server-wide.html.fr
> cvs server: nothing known about server-wide.html.html
> cvs server: nothing known about server-wide.html.ja.jis
> cvs server: nothing known about stopping.html.en
> cvs server: nothing known about stopping.html.fr
> cvs server: nothing known about stopping.html.html
> cvs server: nothing known about suexec.html.en
> cvs server: nothing known about suexec.html.html
> cvs server: nothing known about suexec.html.ja.jis
> cvs server: nothing known about urlmapping.html
> cvs server: nothing known about win_service.html.en
> cvs server: nothing known about win_service.html.html
> cvs server: nothing known about win_service.html.ja.jis
> cvs server: nothing known about apache_header.gif
> cvs server: nothing known about pixel.gif
> cvs server: nothing known about tutorials.html
> cvs server: nothing known about core.html.en
> cvs server: nothing known about core.html.fr
> cvs server: nothing known about core.html.html
> cvs server: nothing known about directive-dict.html.en
> cvs server: nothing known about directive-dict.html.fr
> cvs server: nothing known about directive-dict.html.html
> cvs server: nothing known about directive-dict.html.ja.jis
> cvs server: nothing known about directives.html.de
> cvs server: nothing known about directives.html.en
> cvs server: nothing known about directives.html.fr
> cvs server: nothing known about directives.html.html
> cvs server: nothing known about directives.html.ja.jis
> cvs server: nothing known about index-bytype.html.en
> cvs server: nothing known about index-bytype.html.fr
> cvs server: nothing known about index-bytype.html.html
> cvs server: nothing known about index.html.en
> cvs server: nothing known about index.html.fr
> cvs server: nothing known about index.html.html
> cvs server: not

Re: Tagging 1.3.21 now

[Bill Stoddard]

I am not able to tag the tree. I get the folliwing messages...

Any suggestions?


$ cvs tag APACHE_1_3_21
cvs server: nothing known about index.html.el
cvs server: nothing known about index.html.nn
cvs server: nothing known about index.html.zh.Big5
cvs server: nothing known about bind.html.en
cvs server: nothing known about bind.html.fr
cvs server: nothing known about bind.html.html
cvs server: nothing known about cgi_path.html.en
cvs server: nothing known about cgi_path.html.fr
cvs server: nothing known about cgi_path.html.html
cvs server: nothing known about configuring.html.en
cvs server: nothing known about configuring.html.fr
cvs server: nothing known about configuring.html.html
cvs server: nothing known about configuring.html.ja.jis
cvs server: nothing known about custom-error.html.en
cvs server: nothing known about custom-error.html.fr
cvs server: nothing known about custom-error.html.html
cvs server: nothing known about custom-error.html.ja.jis
cvs server: nothing known about cygwin.html
cvs server: nothing known about dns-caveats.html.en
cvs server: nothing known about dns-caveats.html.fr
cvs server: nothing known about dns-caveats.html.html
cvs server: nothing known about env.html.en
cvs server: nothing known about env.html.html
cvs server: nothing known about env.html.ja.jis
cvs server: nothing known about handler.html.en
cvs server: nothing known about handler.html.html
cvs server: nothing known about handler.html.ja.jis
cvs server: nothing known about index.html.en
cvs server: nothing known about index.html.fr
cvs server: nothing known about index.html.html
cvs server: nothing known about index.html.ja.jis
cvs server: nothing known about install.html.en
cvs server: nothing known about install.html.es
cvs server: nothing known about install.html.fr
cvs server: nothing known about install.html.html
cvs server: nothing known about install.html.ja.jis
cvs server: nothing known about invoking.html.en
cvs server: nothing known about invoking.html.fr
cvs server: nothing known about invoking.html.html
cvs server: nothing known about keepalive.html.en
cvs server: nothing known about keepalive.html.html
cvs server: nothing known about keepalive.html.ja.jis
cvs server: nothing known about logs.html
cvs server: nothing known about mpeix.html
cvs server: nothing known about new_features_1_3.html.en
cvs server: nothing known about new_features_1_3.html.html
cvs server: nothing known about new_features_1_3.html.ja.jis
cvs server: nothing known about new_features_2_0.html
cvs server: nothing known about server-wide.html.en
cvs server: nothing known about server-wide.html.fr
cvs server: nothing known about server-wide.html.html
cvs server: nothing known about server-wide.html.ja.jis
cvs server: nothing known about stopping.html.en
cvs server: nothing known about stopping.html.fr
cvs server: nothing known about stopping.html.html
cvs server: nothing known about suexec.html.en
cvs server: nothing known about suexec.html.html
cvs server: nothing known about suexec.html.ja.jis
cvs server: nothing known about urlmapping.html
cvs server: nothing known about win_service.html.en
cvs server: nothing known about win_service.html.html
cvs server: nothing known about win_service.html.ja.jis
cvs server: nothing known about apache_header.gif
cvs server: nothing known about pixel.gif
cvs server: nothing known about tutorials.html
cvs server: nothing known about core.html.en
cvs server: nothing known about core.html.fr
cvs server: nothing known about core.html.html
cvs server: nothing known about directive-dict.html.en
cvs server: nothing known about directive-dict.html.fr
cvs server: nothing known about directive-dict.html.html
cvs server: nothing known about directive-dict.html.ja.jis
cvs server: nothing known about directives.html.de
cvs server: nothing known about directives.html.en
cvs server: nothing known about directives.html.fr
cvs server: nothing known about directives.html.html
cvs server: nothing known about directives.html.ja.jis
cvs server: nothing known about index-bytype.html.en
cvs server: nothing known about index-bytype.html.fr
cvs server: nothing known about index-bytype.html.html
cvs server: nothing known about index.html.en
cvs server: nothing known about index.html.fr
cvs server: nothing known about index.html.html
cvs server: nothing known about index.html.ja.jis
cvs server: nothing known about mod_env.html.en
cvs server: nothing known about mod_env.html.html
cvs server: nothing known about mod_env.html.ja.jis
cvs server: nothing known about mod_mime.html.en
cvs server: nothing known about mod_mime.html.html
cvs server: nothing known about mod_mime.html.ja.jis
cvs server: nothing known about mod_negotiation.html.en
cvs server: nothing known about mod_negotiation.html.html
cvs server: nothing known about mod_negotiation.html.ja.jis
cvs server: nothing known about mod_setenvif.html.en
cvs server: nothing known about mod_setenvif.html.html
cvs server: nothing known about mod_setenvif.html.ja.jis
cvs ser

Re: [PATCH] Remove the Port directive.

[William A. Rowe, Jr.]

From: "Rodent of Unusual Size" <[EMAIL PROTECTED]>
Sent: Thursday, October 04, 2001 6:26 AM


> Ryan Bloom wrote:
> > 
> > This patch completely deprectates the Port directive.
> > The ServerName directive is now overloaded, so that
> > admins specify the port and name on the same directive.
> > It also makes Listen a required directive.
> 
> I must have missed something.  Just WTH is the motivation
> for all this?  I foresee nasty interactions with
> , among other things.

A four month long conversation on list between just about
everybody, that the BindAddress duplicated Listen, and the
Port directive was too broken for most users to understand.

Now our users have exactly _two_ directives to comprehend:

Listen controls what addresses and ports the server listens on;

Listen 80   [Listen to port 80 on all IP addresses bound to this machine]
Listen 10.0.0.10:80  [Listen to just the 10.0.0.10 IP address, port 80]

ServerName defines the server's OWN name for itself, including 
it's port if it is a nonstandard assignment;

ServerName this.host.com   [assumes the default port 80]
ServerName this.host.com:8080  [specified this server runs on port 8080]

And if you are correct, that this breaks VirtualHost, then we have a
bug and we better fix that before Ryan's commit.  But this makes the
server easier to understand.  Just WTF is a Port directive that doesn't
actually choose a port?  Since Listen overrides the Port directive, I
spend most of my time on newslists asking the user for _every_ bindaddr,
listen, port and servername, which is overkill.

Bill

Tagging 1.3.21 now

[Bill Stoddard]

Hold on commits.

Bill,
Let's save the usertrack patch for 1.3.22. I did a bit of testing/compiling last night 
and
I would prefer not to redo that work.


Bill

Re: cvs commit: apache-1.3/src/main http_main.c

[Jim Jagielski]

[EMAIL PROTECTED] wrote:
> 
>   -static void accept_mutex_init_tpfcore(pool *foo)
>   -{
>   -}
>   +#define accept_mutex_init_tpfcore(x)
>
>static void accept_mutex_child_init_tpfcore(pool *p)
>{
>   @@ -1100,7 +1098,7 @@
>
>accept_mutex_methods_s accept_mutex_tpfcore_s = {
>accept_mutex_child_init_tpfcore,
>   -accept_mutex_init_tpfcore,
>   +NULL,
>accept_mutex_on_tpfcore,
>accept_mutex_off_tpfcore,
>"tpfcore"
>   

Ideally, what I should have done in the 1st place is:

#define accept_mutex_foo_bar NULL

for those nop's that way we would have avoided the above, and all the
structures would be semi-consistant, rather than a mix of real
functions and NULLs... I never documented that those mutex functions that
were null defines mapped to NULL entries in the struct... Worth holding
off 1.3.21 for this??

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

Re: cvs commit: apache-1.3/src/main http_main.c

[Jim Jagielski]

>wrowe   01/10/03 20:59:54
>  
>  -#define accept_mutex_init_tpfcore(x)
>  +static void accept_mutex_init_tpfcore(pool *foo)
>  +{
>  +}
>  

Hold on... I think I have a better way.

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

Re: TPF OK? Was: Re: cvs commit: apache-1.3 STATUS

[Jim Jagielski]

Never mind...
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

Re: 1.3 src/Configure

[Jim Jagielski]

Rodent of Unusual Size wrote:
> 
> I know I was one of the last holdouts that used the old
> src/Configure method, before being converted to APACI.
> Which suddenly makes me wonder.. is there *anyone* that
> still uses src/Configure?  Does anyone know if it still
> works? :-)
> 

It *has* to... 'configure' just provides a front-end to Configure and
creates a specific Configuration.apaci file for Configure to use. :)

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

TPF OK? Was: Re: cvs commit: apache-1.3 STATUS

[Jim Jagielski]

[EMAIL PROTECTED] wrote:
> 
>RELEASE SHOWSTOPPERS:
>
>   -Security issues posted to the appropriate list.
>   -  Status: backport of httpd-2.0/modules/mappers/mod_negotation.c 1.83
>   -  fixes the only remaining negotiation bugaboo.
>   +* none at present
>

Is the reported TPF problem fixed? IIRC there was some problem
possibly related to the AcceptMutex patch...
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  "A society that will trade a little liberty for a little order
   will lose both and deserve neither"

Re: [PATCH] Remove the Port directive.

[Rodent of Unusual Size]

Cliff Woolley wrote:
> 
> +1.  Port vs. Listen has always been one of the things
> people just can't seem to figure out no matter how
> carefully we try to explain it.  Doing it through
> ServerName makes it much more clear what's going on.

Due to the non-1:1 relationship between names and
addresses, and that ports should be associated with
IP addresses rather than names, I feel uncomfortable
with the blanket statement above.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [PATCH] Remove the Port directive.

[Rodent of Unusual Size]

Ryan Bloom wrote:
> 
> This patch completely deprectates the Port directive.
> The ServerName directive is now overloaded, so that
> admins specify the port and name on the same directive.
> It also makes Listen a required directive.

I must have missed something.  Just WTH is the motivation
for all this?  I foresee nasty interactions with
, among other things.
-- 
#kenP-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist  http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

1.3.21 - final for win32?

[William A. Rowe, Jr.]

Well Gunther, here's the tally;

mod_access.c (*)
mod_actions.c (*)
mod_alias.c (*)
mod_asis.c (*)
mod_auth.c (*)
mod_auth_anon.c (+)
mod_auth_db.c (- requires Berkley DB, use mod_auth_dbm)
mod_auth_dbm.c (+)
mod_auth_digest.c (+)
mod_autoindex.c (*)
mod_cern_meta.c (+)
mod_cgi.c (*)
mod_digest.c (+)
mod_dir.c (*)
mod_env.c (*)
mod_example.c (- coding example, not for end users)
mod_expires.c (+)
mod_headers.c (+)
mod_imap.c (*)
mod_include.c (*)
mod_info.c (+)
mod_isapi.c (*)
mod_log_agent.c (- use mod_log_config instead)
mod_log_config.c (*)
mod_log_referer.c (- use mod_log_config instead)
mod_mime.c (*)
mod_mime_magic.c (+)
mod_mmap_static.c (- experimental & not portable)
mod_negotiation.c (*)
mod_proxy.c (+)
mod_rewrite.c (+)
mod_setenvif.c (*)
mod_so.c (*)
mod_speling.c (+)
mod_status.c (+)
mod_unique_id.c (+)
mod_userdir.c (*)
mod_usertrack.c (+)
mod_vhost_alias.c (+)

(*) built in
(+) loadable
(-) unported

And I'd suggest that, with that, Apache on Win32 is pretty darned complete
and sufficient for most users.

Bill

Re: --enable-ssl=shared

[Greg Stein]

Agreed.

mod_ssl.so should pull in the libraries that it needs, whether they are .a
or .so libraries.

Cheers,
-g

On Wed, Oct 03, 2001 at 12:33:07PM -0400, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) 
wrote:
> You're right.. libcrypto/ssl.a should get linked with mod_ssl.so rather than
> httpd. I did try it out initially - with a small hack into the ssl makefile,
> but then gave up - as it involved modifying the autoconf script(something
> which i don't know).
> 
> Thx
> -Madhu
> 
> -Original Message-
> From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 03, 2001 8:47 AM
> To: [EMAIL PROTECTED]
> Subject: Re: --enable-ssl=shared
> 
> 
> On Wed, 3 Oct 2001, Aaron Bannert wrote:
>  
> > So you're saying that libssl.so and libcrypto.so aren't showing up
> > when you run ldd on either httpd or mod_ssl.so? Just for reference,
> > what is ldd giving you for httpd and mod_ssl.so? (You may not want to
> > copy it here, but ldd -v is interesting too).
> 
> no, mine is linked against lib{crypto,ssl}.a
> there are no .so's in /usr/local/ssl/lib
> i'm just noticing now for the first time lib{crypto,ssl}.so in /usr/lib
> 
> but if mod_ssl is built shared, -lssl -lcrypto should get linked against
> mod_ssl.so rather than httpd, right?
> 
> % ldd bin/httpd
> libaprutil.so.0 => /home/dougm/ap/prefork/lib/libaprutil.so.0
> (0x40017000)
> libapr.so.0 => /home/dougm/ap/prefork/lib/libapr.so.0 (0x40028000)
> libm.so.6 => /lib/libm.so.6 (0x40052000)
> libcrypt.so.1 => /lib/libcrypt.so.1 (0x40071000)
> libnsl.so.1 => /lib/libnsl.so.1 (0x400a)
> libdl.so.2 => /lib/libdl.so.2 (0x400b7000)
> libexpat.so.0 => /home/dougm/ap/prefork/lib/libexpat.so.0
> (0x400ba000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x400e1000)
> libc.so.6 => /lib/libc.so.6 (0x400f7000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
> 
> % ldd modules/mod_ssl.so 
> libc.so.6 => /lib/libc.so.6 (0x40032000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)

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

Re: mod_ssl update...

[Greg Stein]

On Wed, Oct 03, 2001 at 08:28:06AM -0700, Justin Erenkrantz wrote:
>...
> Most of the other filters have their logic separated by input and
> output.  mod_ssl combines them into one function.  I think that
> it makes sense to split it out so that input is only handled by
> one function and output is handled by another function.  I'm not
> sure why we have one function attempting to handle input/output.
> Is there a reason why churn() must exist?  Input and output are
> not related to each other.

For SSL, yes: they *are* related. It is possible that OpenSSL may need to
send some bytes to the client in order to read some bytes. I think this is
tied up with the "renegotiation" stuff. I don't really know *why* it would
need to write to the client during a read, but I know it does. That is why
Ben designed it as tied-together input and output filters.

>...
> > I don't think so..As long as we can gather the *full client data* and pass
> > it across, OpenSSL is happy.. The catch here is to capture all the data
> > that's sent by the client, and not to break it into small chunks/pieces.
> 
> What the real deal is that OpenSSL was assumming that it'd get the
> socket bucket back from the core filter and it'd be able to do whatever
> it wanted with it.  That's not possible anymore.

Yup. I'm guessing the logic doesn't like running out of input. When it does,
and it can't simply exit saying "this is all I have right now" (e.g. it is
mid-step during some protocol bits), then it needs to call ap_get_brigade()
again.

> If it is possible to have the core do the heavy lifting (i.e. reading
> from the socket), that is preferred.  I'm just not sure how mod_ssl
> is reading from the socket at all.  It calls ap_get_brigade *and*
> SSL_read - that is a violation of the input filter semantics.  Either
> it reads from the socket on its own or it relies on the core for all
> of the input.

I don't think we ever give it the socket. From looking at the code, it
appears we do an apr_bucket_read() to get some data, write that into some
kind of buffer with BIO_write(), then SSL_read() will return decrypted data
based on what it finds in the BIO.

> > It's definitely possible to use the SSL_* functions - but, then we'll have
> > to expose the socketfd's et al.. Also, it'd be deviating from the other
> > modules of apache, where the filters are *almost* forced to be used. I'd
> > prefer to have the ap_get_brigade_* functionality to read/write the data
> > from the socket.

Euh... no. I believe the basic concept is sound. We simply need to fix the
interaction between the brigade fetched from f->next and the BIO/SSL
functions.

> Yes, I'd prefer it to rely on core, but there are things like *readbytes
> 0 that are completely bogus in the core with SSL.  That's why I'm not 
> sure we can use the core filter anymore.

mod_ssl should never pass readbytes==0 to f->next. As you point out, that is
bogus.

So the next question is "why does it do that?" Simple answer is that the
code is broken. If a caller asks for a line (readbytes==0), then it blindly
passes that to the next filter. Instead, it should ask f->next for BUFSIZE
bytes or somesuch, decode them, then parse a line out and return that.

"How did it work before?" Nobody ever asked it for readbytes==0 through
various happenstance circumstances. The API for input filters said that
somebody *could* do that, but it just didn't happen.

Can you say, "fragile" ? Thought so.

Cheers,
-g

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

Re: cvs commit: apache-1.3 Announcement

[Mark J Cox]

> Justified fixed courier is the single hardest format in the world to
> read.  Having generated in excess of a billion documents in my former
> life, I will play authority on that ;)

Actually I'd not noticed lynx -dump was defaulting to -justify=on :)

Mark

Re: ssl is broken

[Greg Stein]

On Wed, Oct 03, 2001 at 11:35:45AM -0500, William A. Rowe, Jr. wrote:
> From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
> Sent: Wednesday, October 03, 2001 11:15 AM
> 
> > On Wed, Oct 03, 2001 at 08:10:11AM -0500, William A. Rowe, Jr. wrote:
> > > Now ... the core input filter can't decide where to break input, it has to allow
> > > connection filters to insert themselves and decode whatever is read.
> > > 
> > > That means that the core filter needs to be split, and another line input
> > > dequeue filter needs to be inserted as the last 'connection' filter.  That
> > > leaves us ready for the request filter to read 'lines' or 'bytes' and make
> > > decisions based on the lines and bytes read, and fall back on the line input
> > > dequeue to keep the 'next' request's input set-aside for the next request.

No... The input filters have a mode which says "give me a line of input."
*Every* filter must be able to obey that mode. Reading lines can happen at
any point in the input filter stack -- it is *not* just something for the
top level app (httpd) to perform. Consider:

*) httpd needs to read a line for the request ("GET /foo HTTP/1.0")

*) httpd reads lines for the MIME headers

*) HTTP_IN reads lines that specify a chunk size

*) HTTP_IN reads lines for trailer "headers"

In each case, the next filter is supposed to return a single line.

This is exactly why I proposed adding the brigade functions to read lines.
We don't want to build line-reading code into each and every filter.

> > Yes and no.  You are kind of right here - I see why you might want to
> > do that, but that was the previous architecture with HTTP_IN and
> > CORE_IN.  (HTTP_IN was an admittedly bad name for it, but that is 
> > what it tried to do - do readlines.)

Nah. HTTP_IN was simply the only guy who happened to respond properly to the
"*readbytes == 0" mode.

Of course, using count==0 as a mode specifier is whacky. We already pass a
mode parameter, so it should be used. There are two sets of flags that go in
that param: blocking, and read block/line. The "peek" mode and -1 are other
bastard styles; one is "delete any blank lines you see" and the other is
"read everything from the input".

> Then that was the change, to eliminate the HTTP_IN filter?

No.

The idea was to get CORE_IN to handle the various "get_brigade" modes.
Before, it was doing something totally "wrong" -- it returned a brigade that
(effectively) had "everything" in it. That prevented higher level filters
from reading only a specific amount of data from the socket (e.g. whatever
the Content-Length header said). In turn, that meant our input reading and
parsing was busted. (well, it worked, but the coupling created a completely
fragile system)

The second item that was changed was to combine HTTP_IN and DECHUNK. The
former dealt with Content-Length type requests and the latter with chunked
requests. The former could read lines, which happened to support what
DECHUNK was doing.

Of course, when DECHUNK read a line, it used the broken ap_getline()
function. That thing would read from the *top* of the filter stack. That
would actually mean that DECHUNK was re-entered, it would read a line again,
etc etc. I cannot imagine how the original code would have *ever* worked
with chunking on the request.

> Removing HTTP_IN
> and trying to have a CORE_IN of the everything and the bathwater is a broken 
> model.

Yes, it would be. Thankfully, we weren't shooting for that :-)

> You've succeeded in reverting Apache to an http-only server, if that was your
> intention.  As this eliminates our flexibile interoperability for other 
> protocols, I need to veto this patch.

Slow down, Tex :-)

I would suggest learning what happened, and where things are going, before
pulling out that veto card.

> > A lot of the complexity was removed by assuming that only one filter
> > has the -1 brigade.  And, Greg and Ryan have commented that they 
> > would rather see CORE_IN not deal with socket buckets at all but 
> > read directly from the socket.

Yah. The socket bucket and the brigade it was put in is a lot of needless
structure. Consider what is going on there: you're using the brigade to read
from the socket. A bit of buffering is going on to hold unused data that was
read.

But note: you're *copying* data in there.

* apr_bucket_read() to generate a HEAP bucket from the SOCKET bucket

* ->split() to split that bucket into (requested) / (unused)
  
  - the split mallocs and copies a new bucket.

* move the post-split bucket from ctx->b to the passed-brigade


That is a lot of work, and a needless copy. Instead, the CORE_IN can alloc a
buffer of the requested size and do a apr_socket_read() right into that
buffer. Wrap a bucket around it and place it into the passed-brigade.

Of course, you might not read everything requested, and you might also want
to limit the allocation to some maximum number of bytes. (note that the
current code uses apr_brigade_partition() which blocks until the reques

Re: 1.3 src/Configure

[Stipe Tolj]

> Isn't apache-1.3/src/Configure called by apache-1.3/configure ? At least,
> when I fixed my build in src/Configure, things started working. See my patch
> of earlier today.

yes -- Cygwin 1.x uses src/Configure for Makefile variable
configuration too.

Stipe

[EMAIL PROTECTED]
---
Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are

Re: ssl is broken

[Greg Stein]

On Wed, Oct 03, 2001 at 02:34:57PM -0700, Roy T. Fielding wrote:
>...
> I think we have to get off the notion that recent modifications have
> broken mod_ssl

Hell yah. I'm going to follow up to this thread in a sec, but just wanted to
chime in with a high-level comment here. Justin's recent changes have
*improved* the input filter stack. The problems that we're seeing at higher
levels are because those higher levels made assumptions. At the moment, the
various filters are all coupled together, when they should be completely
independent.

> -- it has yet to work correctly with filters.  Any module
> that makes implementation assumptions about the implementation of the
> upstream filter, or the nature of the data being passed through the filter,
> is broken, and I personally think that includes every implementation of
> filters in httpd.  That is why we have a showstopper item about rethinking
> the input filters.

The output filters seem to be quite fine. The input filters have problems,
but Justin just made a big step in fixing them. There are a couple more
steps to do.

The problem is that people are screaming about the first step and saying
"back up" rather than seeing the target and saying "take the next two steps"

Cheers,
-g

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