httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Re: Listen-Protocol branch is ready for review
Date Thu, 02 Jun 2005 21:26:35 GMT
Nick Kew wrote:
>>>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:-)

Well, right now, not much.  But we might have a mod_smtpd out before
September, thanks to Google's Summer of Code.

>>>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
>>>
>>>Added the 'Protocol' directive.  Sets the protocol for a server_rec. Can
>>>inherit from a Listener. (eg, <VirtualHost 0.0.0.0:443> will inherit the
>>>'Protocol https' from the above Listen lines.)
> 
> 
> Where does it live?  It can't live in a namevirtualhost.  If it can
> live in an IP/port virtual host, that'll get confusing!  And, as you
> just demonstrated, it's redundant.  Or am I missing something?


Yes, it is confusing.  How I did it was the 'path of least change'.
Better solutions, including changing how NameVirtualHosts works involve
many far reaching things, and I didn't feel now was a good time to
pursue that path.

The problem lies in that a Single Virtual Host can be spread over 1 or
more listeners.  This becomes a larger problem when you consider binding
to all IP addresses on a host.

What it really 'lives' in is the default virtual host for each ip/port
combo.  The whole concept of a 'default' virtual host leads to much
confusion, and this is just another aspect of it.


>>>Added 'AcceptFilter' directive. This takes 2 args, the protocol and the
>>>name of an Accept Filter. It does include defaults values:
>>>FreeBSD:
>>>  AcceptFilter http httpready
>>>  AcceptFilter https dataready
>>>Linux:
>>>  AcceptFilter http data
>>>  AcceptFilter https data
> 
> 
> Is that an ap_provider or something lower-level?

Just an apr_table..

>>>On Linux, any value will enable TCP_DEFER_ACCEPT.
>>>
>>>Setting the name to 'none' will disable any accept filter for that
>>>protocol.  To fix the nntp test in the Perl-Test-Framework, just add:
>>> Listen 119 nntp
>>> # AcceptFilter nntp none
>>>(The AcceptFilter directive is not required, since it defaults to none,
>>>if the protocol doesn't have a default entry)
> 
> 
> Where are defalt entries defined?  Hardwired, or in httpd.conf?

Hardwired.  I didn't want to add to the default httpd.conf, since in
most cases for people running HTTPS or HTTP sites, this hardwired
default is perfectly valid.

>>>Changed mod_ssl, to enable itself for any virtual hosts that are using
>>>the 'https' protocol.  This means 'SSLEngine on' is no longer required
>>>to enable mod_ssl.  We might not want merge this change, until a more
>>>robust solution for registering protocols could be done. (I would like
>>>to investigate doing that after trunk is branched.)
> 
> 
> Looks good to me.
> 
> 
>>>To test the sandbox branch in your local working copy:
>>>
>>>svn merge -r 168457:HEAD
>>>https://svn.apache.org/repos/asf/httpd/httpd/branches/listen-protocol .
> 
> 
> You around this weekend on IRC?  If I have [any] time ....

Should be able to meet up sometime.

-Paul

Mime
View raw message