Do not unescape forward slashes in the request path (#146).

[cesarblum]

• Set RequestUriBuilder.UseCookedRequestUrl to false to trigger raw parsing.

• The parsing behavior seemed wrong. It was decoding the path and re-encoding it right after. I changed this to that _requestUriString builds a decoded string. %2F is skipped in the decoding process.

• The handling of %uXXXX doesn't seem to work. I tried adding a test for that case and http.sys hangs on it. The Wikipedia entry for percent encoding contains this note:

  There exists a non-standard encoding for Unicode characters: %uxxxx, where xxxx is a UTF-16 code unit represented as four hexadecimal digits. This behavior is not specified by any RFC and has been rejected by the W3C.
  Do not un-escape forward slashes in the request path #146

cc @Tratcher @troydai @davidfowl

[Tratcher]

You can strip out handling for %uXXXX

[cesarblum]

Revert.

[cesarblum]

• Added tests for requests with malformed paths (e.g. /foo%)
• Removed Latin-1 percent-encoded character decoding
• Removed logic related to UseCookedRequestUrl

[cesarblum]

Looking at it in the debugger, this looks like the right thing to do. It's the URL as unescaped by http.sys. We want our escaping to take precedence, but if it fails we have http.sys's to fall back to (that would escape %2F however).

[Tratcher]

Have you found a test case that will trigger this fallback?

[cesarblum]

Not really. Any bad path seems to be caught by http.sys and we never end up in this code. But if we were to hit this situation, having the cooked Uri seems like an appropriate fallback.

[Tratcher]

Have you compared the un-escaping algorithm used here to the one in kestrel?

[cesarblum]

If anything, WebListener's behavior is more robust since it returns a 400 on malformed paths. When Kestrel sees % followed by something it can't decode, it only copies the bytes as is to the "decoded" URL i.e. it does not signal an error for malformed paths. Then somewhere along the stack the pending %s are escaped to %25. I didn't dig enough to find out who is doing that escaping.

[Tratcher]

This is misleading. The % is escaped by the client and sent as %25. That doesn't happen for the other test cases because they're recognized as valid escape sequences.

[Tratcher]

It's especially confusing when the next test says the same input returns 400.

[cesarblum]

Good catch.

[Tratcher]