On 2010-02-26 at 13:32, Paul Querna <p...@querna.org> wrote:

> On Thu, Feb 25, 2010 at 5:20 AM, Eric Covener <cove...@gmail.com> wrote:
>> On Thu, Feb 25, 2010 at 8:03 AM, Dan Poirier <poir...@pobox.com> wrote:
>>
>>> 1) When you use the Protocol directive, which listening ports is it
>>> applied to?
>>>
>>> 2) Why would you choose to use the Protocol directive, instead of adding
>>> the protocol to the Listen directive?
>>
>> Looking at this cold, I think the answer to this is that Protocol is 
>> per-vhost.
>
> I'm not sure it should be, IIRC protocol was introduced before
> protocols on the Listener command, and  their only practical use is
> deciding if we should use kernel level accept filters.
>
> I'm honestly thinking that it could be possible to kill the command,
> if people are happy with having to use the listen command to spec it.
>
> Because it 'inherits' the protocol form the Listen Directive, these
> two configurations are functionally identical:
> Listen 443
> <VirtualHost *:443>
>   Protocol https
>    ...
> </VirtualHost>
>
> And:
> Listen 443 https
> <VirtualHost *:443>
>    ...
> </VirtualHost>
>
> So, I kinda think the value isn't there anymore, and maybe we should
> consider just removing the directive, and tell people to use the
> protocol on the listen command?

I agree.  The only effect of the Protocol setting seems to be to control
what accept filter is applied to the listening socket, so it logically
goes with the listen configuration, not the virtual host.  Putting
different Protocol statements in different VirtualHosts can't work,
since the different virtual hosts can be sharing a single listening
socket, and a given socket can only have one accept filter
configuration.

What would the process be?  Remove the directive from trunk, and label
it deprecated in 2.2's documentation?

Dan

Reply via email to