- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 9 Feb 2008 22:10:15 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Anne van Kesteren <annevk@opera.com>, "WAF WG (public)" <public-appformats@w3.org>
On Feb 9, 2008, at 17:09, Jonas Sicking <jonas@sicking.cc> wrote:
>
> Anne van Kesteren wrote:
>> On Fri, 08 Feb 2008 23:30:46 +0100, Jonas Sicking
>> <jonas@sicking.cc> wrote:
>>> Second, I don't think we should automatically be "fixing up" the
>>> directory uri by prepending and/or appending slashes if they
>>> aren't there. In all other cases we opt to fail if the required
>>> syntax is wrong, which seems like the safer thing when it comes to
>>> security. I think we should apply the same rule here.
>> The current specification does not prepend a slash. It requires the
>> URI to match the abs_path production from RFC 2616. It does append
>> a slash for comparison purposes. I explained this in the other e-
>> mail.
>
> I'd say we should require a initial and a ending '/'. If the path
> doesn't follow that syntax always deny the request.
>
> This follows the general principal of don't do automatic fixups, and
> always deny if something looks wrong.
I'd rather we didn't require the slash. Otherwise, using this header
wouldn't work with URLs of simple CGI scripts. For example:
http://example.com/demo.cgi
This can support both being used as a GET or POST target, as well as
being used with a path:
http://example.com/demo.cgi/user/54
It would be sad to require people to say:
http://example.com/demo.cgi/
...in such cases.
--
Ian Hickson
Received on Sunday, 10 February 2008 06:15:01 UTC