Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Thu, 8 Nov 2012 11:39:04 +0100 (CET)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: Re: svn commit: r1406719 - in /httpd/httpd/trunk: CHANGES
 docs/log-message-tags/next-number include/http_core.h server/core.c
 server/protocol.c
In-Reply-To: <96739BDD-157A-474A-8190-6AFEC2D4524E@sharp.fm>
Message-ID: <alpine.DEB.2.00.1211081127430.20878@eru.sfritsch.de>
References: <20121107165638.E37E223888E4@eris.apache.org>
 <A8BD459A-3281-458F-A03F-05EBB711D8AB@sharp.fm>
 <alpine.DEB.2.00.1211071909150.2653@eru.sfritsch.de>
 <96739BDD-157A-474A-8190-6AFEC2D4524E@sharp.fm>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Wed, 7 Nov 2012, Graham Leggett wrote:

> On 07 Nov 2012, at 8:12 PM, Stefan Fritsch <sf@sfritsch.de> wrote:
>
>> Any suggestions for a syntax? Maybe:
>>
>> HttpProtocol 1.1	# only 1.1
>> HttpProtocol 1.0-	# 1.0 and above
>> HttpProtocol 1.0-1.1	# 1.0 and 1.1
>> HttpProtocol -1.0	# 1.0 and below
>>
>> We could then still add additional flags like +/- strict.
>
> The "-" in front of something means "switch this off" in other 
> directives, I suspect it might cause confusion.

I have already used a similar syntax in RequestReadTimeout. But do you 
think it would be clearer to require two numbers:

HttpProtocol 0.0-1.0		# 1.0 and below
HttpProtocol 1.0-10.100		# 1.0 and above

The upper limit would be rather arbitrary. Of course, I don't see HTTP/2.x 
arriving any time soon.

> Would it make sense to try use globbing (apr_fnmatch)? Perhaps multiple 
> options separated by commas, or an ITERATE separated by spaces?
>
> HttpProtocol *	# any version
> HttpProtocol 1.1	# only 1.1
> HttpProtocol 1.*	# 1.0 and above
> HttpProtocol 1.0,1.1	# 1.0 and 1.1
> HttpProtocol 0.*,1.0	# 1.0 and below

A list of allowed versions would be somewhat more complex to implement, 
because it would require space in core_server_config to store a list (e.g. 
with an apr_array) and we would need to iterate that list when checking 
the request. Only having a minimum and maximum value seems like a less 
over-engineered solution.

Alternatively, if we use a list, then we could limit ourselves to the 
three versions actually in use and not support arbitrary values. Not sure 
if that is a future-proof solution.

> RFC2616 defines the version as follows:
>
>       HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
>
> We could potentially also add a check to make sure that "DIGIT" part is 
> checked to be actual digits, and reject it otherwise.

In the received request? Yes, I think I had that one on my list already.