Re: Listen-Protocol branch is ready for review

Ping?

I really would like at least someone to say, yes, you aren't entirely
crazy, and the extension to the configuration commands makes sense.

If I don't hear anything, I will just merge this into trunk tomorrow.

-Paul

Paul Querna wrote:
> I have completed what I intend to do with the listen-protocol branch.  I
> would love some code review and criticism.
> 
> Currently, the 'httpready' Accept Filter is always applied on FreeBSD.
> This breaks protocols like NNTP where the server must send data first.
> 
> Short: Existing Configurations should behave nearly the same.
> 
> Long:
> Extended the 'Listen' directive.  Now optionally takes a protocol.  If
> none is specified, it uses 'http'. (backwards compat)
> 
> # both of these are equivalent.
> Listen 0.0.0.0:80
> Listen 0.0.0.0:80 http
> # defaults to http
> Listen 0.0.0.0:8080
> # Force these to HTTPS
> Listen 0.0.0.0:443 https
> Listen 0.0.0.0:8443 https

Re: Listen-Protocol branch is ready for review

Paul Querna wrote:

>>I have completed what I intend to do with the listen-protocol branch.  I
>>would love some code review and criticism.

I'd love some time ...

>>Currently, the 'httpready' Accept Filter is always applied on FreeBSD.
>>This breaks protocols like NNTP where the server must send data first.

OK, I can see that the idea in general makes sense, and that's
an instance of why.

OTOH, how useful is apache really for nontrivial non-http applications,
given just how much lives on the very HTTP-centric request_rec?
Not that I'm trying to raise an objection

>>Short: Existing Configurations should behave nearly the same.

Great.

>>Long:
>>Extended the 'Listen' directive.

OK.

  Now optionally takes a protocol.  If
>>none is specified, it uses 'http'. (backwards compat)
>>
>># both of these are equivalent.

[STATUS] (httpd-2.1) Wed Jun 1 23:46:21 2005

APACHE 2.1 STATUS:                                              -*-text-*-
Last modified at [$Date: 2005-05-02 16:21:40 -0400 (Mon, 02 May 2005) $]

The current version of this file can be found at:
http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS

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

    2.1.5   : in development
    2.1.4   : not released.
    2.1.3   : Released on  2/22/2005 as alpha.
    2.1.2   : Released on 12/08/2004 as alpha.
    2.1.1   : Released on 11/19/2004 as alpha.
    2.1.0   : not released.

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

    * http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
    * http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS
    * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS

Contributors looking for a mission:

    * Just do an egrep on "TODO" or "XXX" in the source.

    * Review the bug database at: http://issues.apache.org/bugzilla/

    * Review the "PatchAvailable" bugs in the bug database:

[STATUS] (httpd-2.0) Wed Jun 1 23:46:14 2005

APACHE 2.0 STATUS:                                              -*-text-*-
Last modified at [$Date: 2005-05-31 20:00:18 -0400 (Tue, 31 May 2005) $]

The current version of this file can be found at:
http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS

Release history:

    2.0.55  : in development
    2.0.54  : released April 17, 2005 as GA.
    2.0.53  : released February 7, 2005 as GA.
    2.0.52  : released September 28, 2004 as GA.
    2.0.51  : released September 15, 2004 as GA.
    2.0.50  : released June 30, 2004 as GA.
    2.0.49  : released March 19, 2004 as GA.
    2.0.48  : released October 29, 2003 as GA.
    2.0.47  : released July 09, 2003 as GA.
    2.0.46  : released May 28, 2003 as GA.
    2.0.45  : released April 1, 2003 as GA.
    2.0.44  : released January 20, 2003 as GA.
    2.0.43  : released October 3, 2002 as GA.
    2.0.42  : released September 24, 2002 as GA.
    2.0.41  : rolled September 16, 2002.  not released.
    2.0.40  : released August 9, 2002 as GA.
    2.0.39  : released June 17, 2002 as GA.
    2.0.38  : rolled June 16, 2002.  not released.
    2.0.37  : rolled June 11, 2002.  not released.
    2.0.36  : released May 6, 2002 as GA.
    2.0.35  : released April 5, 2002 as GA.
    2.0.34  : tagged March 26, 2002.

Re: svn commit: r178990 - in /httpd/httpd/trunk: CHANGES server/config.c

On Sun, May 29, 2005 at 09:39:40PM -0000, Paul Querna wrote:
> Author: pquerna
> Date: Sun May 29 14:39:39 2005
> New Revision: 178990
> 
> URL: http://svn.apache.org/viewcvs?rev=178990&view=rev
> Log:
> - Use a hash for the configuration command lookup implementation.  Now
> modules can properly directives without dependence on the LoadModule
> order.

It seems this has broken the test suite somehow, it's failing to start
up with mod_ssl issuing the error:

[Thu Jun 02 14:01:14 2005] [error] Init: Multiple RSA server certificates not allowed

if I revert this revision it works again.  Any ideas?

joe

Re: svn commit: r178990 - in /httpd/httpd/trunk: CHANGES server/config.c

On Thu, Jun 02, 2005 at 02:05:05PM +0100, Joe Orton wrote:
> On Sun, May 29, 2005 at 09:39:40PM -0000, Paul Querna wrote:
> > Author: pquerna
> > Date: Sun May 29 14:39:39 2005
> > New Revision: 178990
> > 
> > URL: http://svn.apache.org/viewcvs?rev=178990&view=rev
> > Log:
> > - Use a hash for the configuration command lookup implementation.  Now
> > modules can properly directives without dependence on the LoadModule
> > order.
> 
> It seems this has broken the test suite somehow, it's failing to start
> up with mod_ssl issuing the error:
> 
> [Thu Jun 02 14:01:14 2005] [error] Init: Multiple RSA server certificates not allowed
> 
> if I revert this revision it works again.  Any ideas?

The problem is that the directive->module mapping is never getting
removed when the DSO is unloaded, so during normal startup each
directive will appear in the hash table twice for DSOs; then once more
for each restart.  Hence mod_ssl is confused.

This is pretty dangerous since the module might *not* be reloaded again
during a restart but the reference remains.  And since everything is
allocated out of the global pool it's leaking memory across restarts
too.

plus much style badness for a third criticism, while I'm here ;)

me working on bugs??

Re: me working on bugs??

ed elliott wrote:
> hi,
>  
> I have been having a look at apache quite a lot lately and so I thought 
> I would have a look at some bugs.
>  
> I picked out a few I thought I could work on, added a comment and 
> checked the "Accept Bug" thinking that a) It was ok to assign bugs to 
> myself to work on them and b) that it would actually assign them to me.
>  
> Am I allowed to do this as it didn't assign them to me but to 
> bugs <at> httpd.apache.org <mailto:bugs <at> httpd.apache.org>.
> cheers

I don't think we really care whether bugs are assigned or not.  But it 
is important *not* to change the assigned-to address, since that address 
assures that the bug changes are sent to our tracking mailing list.

What I suggest you do is simply add yourself to the cc: list for the 
bug, and add a comment saying "I'm working on this" (or something similar).

Joshua.

Re: me working on bugs??

Re: me working on bugs??

At 12:33 PM 6/2/2005, ed elliott wrote:
> 
>I picked out a few I thought I could work on

Thanks!!!  Always looking for helpers.

>Am I allowed to do this as it didn't assign them to me but to
<mailto:bugs <at> httpd.apache.org>bugs <at> httpd.apache.org. 

Don't do that!!!

You rip the bug right out of the bug tracking email list.

You may add yourself as a cc:, or what I do, set up a query of
bugs you have responded to (which makes it easier to look at the
ones you have observations about.

One more useful clue, keyword it PatchAvailable once you have
a solution (attached) so that committers seeking low-hanging fruit
can prune some off and close the bugs.

Bill