Dream and .Net 2.0 sp1

[satook]

Hi,
I'm using dream on a Win2k3 server and an XP box, for dev. On both machines, when I update .Net 2.0 framework to sp1, the Regex match in XURI.TryParse() breaks with segments that have spaces in them, i.e. "GET:/campaigns/{name}". If I pass in a campaign with a space in it's name, the regex match fails. The URL's are being properly encoded, with %20 instead of actual spaces.

Not sure what's wrong. My solution so far has been to avoid sp1, but that's a bit of a problem long term

If you need any more info, I'll be checking back

Cheers

[SteveB]

Sounds like the URI is being decoded before it reaches Dream. Are you running Dream as a service or under IIS?

In Deki Wiki, we ran into a similar issue on Apache and mod_proxy. In that case, we were forced to double encode segments which contained spaces: http://server/segment%2520space

[satook]

I'm using the Host version.
I was running host in debug mode and breakpointed to make sure dream was getting the proper encoded string in the request, i.e. %20's and such.

I also added some extra info to the exception that was getting thrown in custExtraErrorInfo to tell where in TryParse it was failing. This confirmed that the issue still ocured in release mode as well.

[SteveB]

Can you verify if this problem only occurs for spaces, but also for other encoded characters? Like '/' = %25 or '[' = %5b?

[satook]

I'm hitting the dream host service directly now, no proxies. I tried from %20 to %2f and %5b. The following characters caused a regex fail on sp1 but not on 2.0 vanilla.
- " or %22
- space or %20
- [ or %5b

The rest worked fine, which is really strange. I made sure they all came through as %xx to dream as well so it's a little odd really.
I can try more if you like...

[SteveB]

I opened an issue ticket on it and will take a look at it:
http://bugs.opengarden.org/view.php?id=4235

[satook]

Thanks will be good to see if what's causing the issue.

[andrewstew]

Hi Again,
It's Satook. I forgot my password and for whatever reason I never put an email address in there. I came accross this issue again, but this time with dotNet 3.5. I did a bit more digging this time and thought you'd like to know what I found. Here is a URL I put in Firefox and what it appeared as in whireshark and in dream 1.5.7 running on different versions of dotNet:

Firefox: "http://crlx113798:8081/insurance%20line/poop%2Fhat"
Wireshark: "http://crlx113798:8081/insurance%20line/poop%2Fhat"
Dream 1.5.7 dotNet 2.0: httpContext.Request.URi.OriginalString: "http://crlx113798:8081/insurance%20line/poop%2fhat"
Dream 1.5.7 dotNet 2.0 sp1: httpContext.Request.URL.OriginalString: "http://crlx113798:8081/insurance line/poop/hat"
Dream 1.5.7 dotNet 2.0 sp2: httpContext.Request.URL.OriginalString: "http://crlx113798:8081/insurance line/poop/hat"
Dream 1.5.7 dotNet 3.5: httpContext.Request.URL.OriginalString: "http://crlx113798:8081/insurance line/poop/hat"

The httpContext.Request.URL I'm refering to mindtouch.core.httptransport class line 161 where the RequestHander method does it's thing.
The from 2.0 SP1 onwards, the URL property is returning the incorrect OriginalString value. This means that the XUri dream class is getting the decoded version of the URL string and thus spaces cause it to fail. Worse, if you put a %2F in the path then it gets interpretted as a segment seperator. I changed the code that contructs the XUri object to instead hand over the raw URL, which I composed as follows:

string rawURL = string.Format("{0}://{1}{2}", httpContext.Request.Url.Scheme, httpContext.Request.UserHostName, httpContext.Request.RawUrl);

If I hand this in to XUri, it gets a correct, undecoded string for the URL and everything works as intended.

Note: I ran dream 1.5.7 on Visual Studio 2005 for the dotNet 2.0/sp1/sp2 tests and on VS2008 for the dotNet 3.5 tests.

I also checked the 1.6.0 version of dream and the error is still present, as you're still constructing the XUri object using the HttpListenerRequest.URL.OriginalString property, which is decoded. Seems like MS made a breaking change in how HttpListenerRequest constructs it's URL object and never noticed. It sure isn't given the raw URL, as when I tested doing this myself the OriginalString property was correct.

Cheers

[arnec]

Have you checked Dream 1.7.0 or 2.0? I know we addressed XUri issues with .NET 3.5 and I think it went into 1.7.0 or 1.7.1