You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Graham Leggett <mi...@sharp.fm> on 2012/11/07 18:05:25 UTC
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, sf@apache.org wrote:
> Author: sf
> Date: Wed Nov 7 16:56:38 2012
> New Revision: 1406719
>
> URL: http://svn.apache.org/viewvc?rev=1406719&view=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
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Nov 7, 2012, at 12:05 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 7 Nov 2012, at 17:56, sf@apache.org wrote:
>
>> Author: sf
>> Date: Wed Nov 7 16:56:38 2012
>> New Revision: 1406719
>>
>> URL: http://svn.apache.org/viewvc?rev=1406719&view=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
Posted by Stefan Fritsch <sf...@sfritsch.de>.
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
Posted by Tim Bannister <is...@jellybaby.net>.
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 – isoma@jellybaby.net
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
Posted by Stefan Fritsch <sf...@sfritsch.de>.
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
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
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 <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.
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
Posted by Stefan Fritsch <sf...@sfritsch.de>.
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.
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
Posted by Graham Leggett <mi...@sharp.fm>.
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.
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
--
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
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Wed, 7 Nov 2012, Graham Leggett wrote:
> On 7 Nov 2012, at 17:56, sf@apache.org wrote:
>
>> Author: sf
>> Date: Wed Nov 7 16:56:38 2012
>> New Revision: 1406719
>>
>> URL: http://svn.apache.org/viewvc?rev=1406719&view=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
Posted by André Malo <nd...@perlig.de>.
On Wednesday 07 November 2012 22:16:46 Graham Leggett wrote:
> On 07 Nov 2012, at 10:35 PM, André Malo <nd...@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
Posted by Graham Leggett <mi...@sharp.fm>.
On 07 Nov 2012, at 10:35 PM, André Malo <nd...@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
--
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
Posted by André Malo <nd...@perlig.de>.
* Graham Leggett wrote:
> On 7 Nov 2012, at 17:56, sf@apache.org wrote:
> > Author: sf
> > Date: Wed Nov 7 16:56:38 2012
> > New Revision: 1406719
> >
> > URL: http://svn.apache.org/viewvc?rev=1406719&view=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>