Opened 6 years ago

Closed 6 years ago

#443 closed design (wontfix)

Whitespace in request-target

Reported by: mnot@… Owned by: draft-ietf-httpbis-p1-messaging@…
Priority: normal Milestone: unassigned
Component: p1-messaging Severity: In WG Last Call
Keywords: Cc:


p1 3.1.1 says:

Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters directly instead of properly encoding or excluding the disallowed characters. 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 note that the practice of correcting this is fairly widespread; e.g., in Squid, the default is to strip the whitespace, and IIRC has been for some time:

I think that the Squid documentation needs to be corrected, because the text in RFC2396 (and later in 3986) is about URIs in contexts like books, e-mail and so forth, not protocol elements:

My question is why this is a SHOULD / SHOULD NOT. We say that SHOULD-level requirements affect conformance unless there's a documented exception here:

... but these requirements don't mention any exceptions. Is the security risk here high enough to justify a MUST / MUST NOT? If not, they probably need to be downgraded to ought (or an exception needs to be highlighted).

Change History (3)

comment:1 Changed 6 years ago by mnot@…

  • Component changed from non-specific to p1-messaging
  • Owner set to draft-ietf-httpbis-p1-messaging@…
  • Severity changed from Active WG Document to In WG Last Call

comment:2 Changed 6 years ago by mnot@…

Proposal from list:

Clients MUST NOT send user-typed delimiters and embedded whitespaces as-is in URIs, and SHOULD either encode them, strip them. Alternatively they MAY simply refuse to perform the request.

Servers and intermediaries MUST NOT try to fix embedded spaces and delimiters in URIs, as doing so could lead to interoperability issues and make several components in the chain understand different things. When a request does not parse exactly as defined in the ABNF, an error 400 (Bad Request) MUST be returned to the client.

comment:3 Changed 6 years ago by mnot@…

  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.