Re: p1: whitespace in request-target

Hi Roy,

On Sun, May 19, 2013 at 12:58:47PM -0700, Roy T. Fielding wrote:
(...)
> The text currently in p1 (latest) is
> 
>    The request-target identifies the target resource upon which to apply
>    the request, as defined in Section 5.3.
> 
>    Recipients typically parse the request-line into its component parts
>    by splitting on whitespace (see Section 3.5), since no whitespace is
>    allowed in the three components.  Unfortunately, some user agents
>    fail to properly encode or exclude whitespace found in hypertext
>    references, resulting in those disallowed characters being sent in a
>    request-target.
> 
>    Recipients of an invalid request-line SHOULD respond with either a
>    400 (Bad Request) error or a 301 (Moved Permanently) redirect with
>    the request-target properly encoded.  Recipients SHOULD NOT attempt
>    to autocorrect and then process the request without a redirect, since
>    the invalid request-line might be deliberately crafted to bypass
>    security filters along the request chain.
> 
> I think the requirement is adequately explained.

Yes, I remember it now, it was already discussed several months ago.

> It is a SHOULD instead
> of a MUST because there was no specific error handling defined for this
> case in 2616.

Well, it says at 3.2.1 that the format of RFC2396 applies to URIs, and
2396 explicitly excludes spaces and control characters from allowed
characters used in URIs.

In 5.1, 2616 says :

  Request-Line = Method SP Request-URI SP HTTP-Version CRLF,
  Request-URI = "*" | absoluteURI | abs_path | authority

And unless I missed something, none of them was allowed to contain a
space (except SP of course :-)).

Is this because of the following sentence a few lines below that you're
saying the error handling was not defined ?

  "Servers SHOULD respond to invalid Request-URIs with an appropriate
   status code."

Because then I agree that I found nothing mandating anyone to return
400 when receiving an invalid request, which is a bit sad but we'll
have to live with this I guess :-/

Best regards,
Willy

Received on Sunday, 19 May 2013 21:50:49 UTC