On Friday 16 November 2012, Roy T. Fielding wrote:
> 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.
For 2.6/3.0, I agree. But for 2.4, I would rather do it in steps.
First add the directive, defaulting to 0.9 enabled. One or two
versions later, change default to disabled. If it didn't cause any
complaints, maybe remove 0.9 support completely some time later.
> 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.
About the newer versions, I am not sure about the use cases either. We
could remove the upper limit and only have a minimum allowed version.
But AFAICS, disabling 1.0 is only good for Graham's use case. It could
also be done with
<If "! -T %{IS_SUBREQ} && %{SERVER_PROTOCOL} = 'HTTP/1.0'">
Require all denied
</If>
If that is good enough for the rather exotic use case, we could go
back to a simple flag to enable/disable 0.9.
NB: The IS_SUBREQ part is necessary because some sub requests set r-
>protocol to "INCLUDED". This could be avoided if we expose r-
>proto_num in the expression parser. That one seems to be preserved
across sub requests and it also would make checking against a range of
versions easier:
<If "%{SERVER_PROTOCOL_NUM} -lt 1001">
Require all denied
</If>
Graham, what do you think?
Cheers,
Stefan
