httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
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
Date Thu, 08 Nov 2012 10:39:04 GMT
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.

Mime
View raw message