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
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
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
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
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
On Wednesday 07 November 2012 22:16:46 Graham Leggett wrote: On 07 Nov 2012, at 10:35 PM, André Malo n...@perlig.de wrote: It feels wrong targeting 0.9 only, would it be possible to do this in a generic way, say by listing the ones accepted, or by specifying a minimum? Hmm, what would be the use case? I see it with HTTP/0.9, but I don't see it with = HTTP/1.0. I'd prefer kind of duck typing for those, like asking is a valid host header present? - which is already possible. I've had problems in the past with HTTP/1.0 requests to restful services causing keepalive problems with load balancers, and I'd like to be able to ban HTTP/1.0 requests, allowing HTTP/1.1 only. Huh. It sounds more like fixing the loadbalancers would be the way to go. Most non-browser clients don't speak HTTP/1.1 anyway. nd
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
On Wed, 7 Nov 2012, Tim Bannister wrote:
On 7 Nov 2012, at 18:12, Stefan Fritsch wrote:
On Wed, 7 Nov 2012, Graham Leggett wrote:
New directive HttpProtocol which allows to disable HTTP/0.9 support.
It feels wrong targeting 0.9 only, would it be possible to do this in a generic
way, say by listing the ones accepted, or by specifying a minimum?
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
Does it need its own directive? How about a new environment variable and
Require:
Require expr %{HTTP_PROTOCOL} -gt 1.1
I realise that won't work as things stand, because -gt only handles integers.
Maybe another binary operator could allow decimals?
NB. SERVER_PROTOCOL would not be suitable because the initial “HTTP/” makes it
harder to do math.
I would prefer a dedicated directive: If you use authorization for that,
you have to take care that it is not overriden by per-directory authz
directives. Also, while evaluating an ap_expr is faster than e.g. using
mod_lua, it is still a relatively complex operation. And I expect a lot of
admins would like to disable 0.9, so having a way that has only minimal
impact on performance would be better. Finally, I am not 100% sure that
there are no code paths that cause a HTTP/0.9 error response to be sent
before the Requrire or If is executed. The dedicated directive is
certain to catch all uses of HTTP/0.9.
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
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.
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
On 7 Nov 2012, at 17:56, s...@apache.org wrote: Author: sf Date: Wed Nov 7 16:56:38 2012 New Revision: 1406719 URL: http://svn.apache.org/viewvc?rev=1406719view=rev Log: New directive HttpProtocol which allows to disable HTTP/0.9 support. It feels wrong targeting 0.9 only, would it be possible to do this in a generic way, say by listing the ones accepted, or by specifying a minimum? Regards, Graham --
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
On Nov 7, 2012, at 12:05 PM, Graham Leggett minf...@sharp.fm wrote: On 7 Nov 2012, at 17:56, s...@apache.org wrote: Author: sf Date: Wed Nov 7 16:56:38 2012 New Revision: 1406719 URL: http://svn.apache.org/viewvc?rev=1406719view=rev Log: New directive HttpProtocol which allows to disable HTTP/0.9 support. It feels wrong targeting 0.9 only, would it be possible to do this in a generic way, say by listing the ones accepted, or by specifying a minimum? Almost seems like using Limit would even be better... :/
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
On Wed, 7 Nov 2012, Graham Leggett wrote: On 7 Nov 2012, at 17:56, s...@apache.org wrote: Author: sf Date: Wed Nov 7 16:56:38 2012 New Revision: 1406719 URL: http://svn.apache.org/viewvc?rev=1406719view=rev Log: New directive HttpProtocol which allows to disable HTTP/0.9 support. It feels wrong targeting 0.9 only, would it be possible to do this in a generic way, say by listing the ones accepted, or by specifying a minimum? 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.
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
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. 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 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. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
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
On 7 Nov 2012, at 18:12, Stefan Fritsch wrote:
On Wed, 7 Nov 2012, Graham Leggett wrote:
New directive HttpProtocol which allows to disable HTTP/0.9 support.
It feels wrong targeting 0.9 only, would it be possible to do this in a
generic way, say by listing the ones accepted, or by specifying a minimum?
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
Does it need its own directive? How about a new environment variable and
Require:
Require expr %{HTTP_PROTOCOL} -gt 1.1
I realise that won't work as things stand, because -gt only handles integers.
Maybe another binary operator could allow decimals?
NB. SERVER_PROTOCOL would not be suitable because the initial “HTTP/” makes it
harder to do math.
--
Tim Bannister – is...@jellybaby.net
smime.p7s
Description: S/MIME cryptographic signature
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
* Graham Leggett wrote: On 7 Nov 2012, at 17:56, s...@apache.org wrote: Author: sf Date: Wed Nov 7 16:56:38 2012 New Revision: 1406719 URL: http://svn.apache.org/viewvc?rev=1406719view=rev Log: New directive HttpProtocol which allows to disable HTTP/0.9 support. It feels wrong targeting 0.9 only, would it be possible to do this in a generic way, say by listing the ones accepted, or by specifying a minimum? Hmm, what would be the use case? I see it with HTTP/0.9, but I don't see it with = HTTP/1.0. I'd prefer kind of duck typing for those, like asking is a valid host header present? - which is already possible. nd -- Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3) -- aus einer Rezension http://pub.perlig.de/books.html#apache2
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
On 07 Nov 2012, at 10:35 PM, André Malo n...@perlig.de wrote: It feels wrong targeting 0.9 only, would it be possible to do this in a generic way, say by listing the ones accepted, or by specifying a minimum? Hmm, what would be the use case? I see it with HTTP/0.9, but I don't see it with = HTTP/1.0. I'd prefer kind of duck typing for those, like asking is a valid host header present? - which is already possible. I've had problems in the past with HTTP/1.0 requests to restful services causing keepalive problems with load balancers, and I'd like to be able to ban HTTP/1.0 requests, allowing HTTP/1.1 only. Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
