On Nov 8, 2012, at 2:39 AM, Stefan Fritsch wrote: > On Wed, 7 Nov 2012, Graham Leggett wrote: > >> On 07 Nov 2012, at 8:12 PM, Stefan Fritsch <s...@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.
FWIW, I don't think any of this should be configurable. HTTP/0.9 is on the chopping block -- it cannot be reasonably supported on networks today because routing is based on the Host header field. We should just delete all backasswards. HTTP/1.x must be supported to be 1.1 compliant and there is no point in allowing configuration of support for future protocols when we have nothing capable of processing those protocols. Only new protocol modules can determine what else is supported. ....Roy
