HttpRequest.path should preserve URL encoding

[nex3]

HttpRequest.path is un-URL-encoded. For example, a request to "/foo%2Fbar" will have a path of "/foo/bar".

[madsager]

Nathan, could you provide a bit more context. When is it a problem for you that you get the actual string instead of the URL encoding?

---

Set owner to @sgjesse.

[nex3]

This is a problem because it's impossible to distinguish between characters that mean something in the URL (e.g. "/") and characters that are just encoding data (e.g. "%2F"). A specific example is a GET request to "/package/foo%2Fbar"; this should return data about the "foo/bar" package rather than trying to look up the url "/package/foo/bar".

[sgjesse]

Thanks for clarifying. Of cause we need to handle the URL encoding differently. However just making HttpRequest.path the unencoded path seems to simple. How about having a canonicalization algorithm for the path.

As far as I can see we only need to treat %20 (space), %2F (/) and %3F (?) specially.

The path part of the URI is up to, and not including the first literal ? (not %3F).

The canonicalized path is the URL-decoded path except that:

  %20 (space) is decoded to +
  %2F (/) is not decoded
  everything else is decoded (including %3F (?))

Examples

  /123/456 => /123/456
  /1%32%33/%345%36 => /123/456
  /1/2/3 => /1/2/3
  /1%2F2%2F3/%345%36 => /1%2F2%2F3/456
  /1+2%203/%345%36 => /1+2+3/456
  /1%2F2%3F3/%3F%35%20 => /1%2F2?3/%3F5+

If we don't do something like this every user need to do URL-decoding on the path.

We could still add a pathRaw to get the un-decoded path.

---

Added Accepted label.

[nex3]

Every user still needs to do URL-decoding on the path in order to handle a potential %2F, so doing decoding of characters other than %2F doesn't really matter one way or the other.

I don't think it's correct to decode %20 to + -- it adds another case that users need to worry about decoding. I'd rather see "+" get automatically changed to " " or "%20". Decoding "%20" to " " would be more consistent with the overall philosophy of automatically decoding everything, and wouldn't cause any ambiguities.

If you do decode "%20" to "+", be sure to leave "%2B" (+) encoded.

[sgjesse]

Added this to the M5 milestone.

[sgjesse]

Some time ago we removed HttpRequest.path and now one has to use HttpRequest.uri.path. This getter provides the path in its encoded form.

---

Added Fixed label.

[kevmoo]

Removed Area-IO label.
Added Area-Library, Library-IO labels.