I wasn't really sure the use case for the & check (I assumed you wanted to handle the case where someone HTML encoded it instead).. so I'll focus on the
FYI: I am able to reproduce this even on today's latest source (25767).
I loaded up the trunk solution and ran Tutorial1 with a small modification to the /hello response logic:
if (request.Uri.AbsolutePath == "/hello")
System.Text.StringBuilder sb = new System.Text.StringBuilder();
sb.AppendLine("Hello to you too!<br/><br/>");
foreach (HttpInputItem param in request.Param)
sb.AppendLine(param.ToString() + "<br/>");
For the following URL you would expect to see testparam = here&there printed out (because that is the output format of the ToString() method on HttoInputItem) but that is not what happens.
Here is the actual output:
Hello to you too!
testparam = here
The parsing code (as it) treats the encoded & (%26) as an actual
& and therefore starts parsing a new parameter (which results in the broken
testparam parameter and the blank name for the there value).
The code change I made above was simply to returns false; after the
%26 and & checks (meaning this character (and those I'm advancing in outIndex are not specifying the start of a new parameter).
I hope this helps.