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: r1426877 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c server/util.c server/vhost.c
Date Sun, 30 Dec 2012 20:46:34 GMT
Hi Roy,

On Sunday 30 December 2012, Roy T. Fielding wrote:
> Thanks for this work, but I don't consider HTTP conformance to be
> an option.  These are checks we should be making while parsing
> the received message, not as a separate pass, and in many cases
> they are required to result in a 400, 500, or 502 response.

Some of the new checks are bound to cause problems with existing sites 
and/or clients. I think we need to offer some soft migration path. 
Like

1) make the checks an option, defaulting to off
2) change the default to on
3) make the checks mandatory

I guess the time between the steps depends on the feedback we get from 
users. I expect one year may be reasonable. Of course, we may choose 
to make some checks mandatory earlier, if they are very unlikely to 
break things.

For some parts, the new checks are done during the normal parsing. But 
in order to allow them to be switched off, some separation was 
necessary.

> I am trying to get HTTPbis ready for last call this week.
> After that, I will be looking into making the changes in httpd,
> and I won't be using a configurable option.  I suggest we just
> remove that part and iterate on these checks as we go.
>
> The current HTTP/1.1 drafts are at
> 
>  
> http://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest
> /
> 
> and the message parsing requirements are in p1-messaging.html

Thanks, I hadn't looked at this previously, but it seems to be mostly 
in line to what I have implemented. HTTPbis mandates some more 
restrictions that should be checked, too.
 
> BTW, the protocol version is now restricted to uppercase and
> one digit per major and minor, so we can simplify that check
> to a very specific "HTTP/[0-9].[0-9]".
> 
> And, yes, it is possible to have a valid empty Host because
> HTTP can be used with a proxy for any URI (including URNs).

OK, I will change the protocol parsing and remove the comment about 
empty Host headers.

> ....Roy
> 
> On Dec 29, 2012, at 5:23 PM, sf@apache.org wrote:
> > Author: sf
> > Date: Sun Dec 30 01:23:24 2012
> > New Revision: 1426877
> > 
> > URL: http://svn.apache.org/viewvc?rev=1426877&view=rev
> > Log:
> > Add an option to enforce stricter HTTP conformance
> > 
> > This is a first stab, the checks will likely have to be revised.

Mime
View raw message