Prototype: unescapse path #269
Conversation
| @@ -623,6 +626,11 @@ private bool TakeStartLine(SocketInput input) | |||
| return false; | |||
| } | |||
|
|
|||
| char[] requestUriChars; | |||
| var rawPathLength = beginPath.GetCharArray(endPath, out requestUriChars); | |||
| var decodedLength = UrlPathDecoder.DecodeInPlace(requestUriChars, rawPathLength); | |||
There was a problem hiding this comment.
DecodeInPlace should take beginPath/endPath iterators, modify the bytes in-place to unescape % sequences, and return the new endPath position rather than copy to an intermediate char[]. This also means the DecodeInPlace method does not need to understand utf-8 sequences, because the subsequent conversion from byte[] to string via UTF8 encoder will take care of that concern.
There was a problem hiding this comment.
To achieve the goal of in place updating in the memory pool block I need to significantly change the UrlPathDecoder so that it accepts two iterator like objects to operator. The existing logic heavily depends on random access for verify UTF8 coding.
I think it's do doable but we won't be able to share the Decoder since it will be highly specified for Kestrel. And I'm more worried about progress at this point to redo this decoder at this point. I'm more than willing to make it happen after rc1.
There was a problem hiding this comment.
All right. I'm working out a prototype on this idea now. I'll send a separate PR for that. But I'd like to keep this floating as a fall back.
There was a problem hiding this comment.
This is the prototype: #274
|
Replaced by #274 |
Issue #124
To unescape the path while read the first line to the request.
Note:
HttpAbstraction. It is currently being reviewed: Url Path Decoder HttpAbstractions#448.MemoryPoolIterator2to return the rawchar[]instead of astringas a result the decoding is able to be operated in place to avoid additional allocation.Follow up:
/cc @halter73 @Tratcher @davidfowl @lodejard @muratg