The URL you see in the IIRF logfile is the final URL returned to the server. There's no discrepancy possible.
I do think there's a problem with handling URLs with spaces - According to
IETF RFC2396 (URI), which is referenced by IETF RFC 2616 (HTTP), spaces must be escaped as %20 or encoded as +. I think I may have said this in the other discussion you referenced. But if you're getting them then you may be forced
to deal with them.
One way to work around this is to use different rules for URLs with spaces. It's not a general solution but it might be good enough for your purposes.
# handle URLs without spaces
RewriteRule ^(/path/to/cakesite/(?!app/webroot)([^\x20]+))$ /path/to/cakesite/app/webroot/$2 [I,L]
# handle URLs with one space
RewriteRule ^(/path/to/cakesite/(?!app/webroot)(([^\x20]+)(\x20([^\x20]+))))$ /path/to/cakesite/app/webroot/$3+$5 [I,L]
Some explanation: The first rule includes a subpattern like this: (?!app/webroot). This is a non-capturing negative lookahead pattern. It doesn't capture. It's negative, and it looks ahead. It evaluates to true when the test string
DOES NOT match app/webroot, which is what I think you're trying to do with the RewriteCond $1 thing. So you could use that non=capturing negative lookahead in place of the final RewriteCond of the three.
Ok, now, getting to the important stuff: the subpattern ([^\x20]+) matches any sequence of one or more characters that is not a space (\x20). Therefore, the first rule above works for URLs that have no spaces, and rewrites it appropriately.
The second rule above, uses the same non-capturing negative lookahead. It then uses the same beginning capturing subpattern - a series of one or more characters, none of which is space. This is then followed by another capturing group, which begins
with space (\x20), and follows with another series of one or more characters, none of which is space, and this series is captured into its own group via parens (). The effect is to match and tokenize a URL that has a single embedded space. The
capture groups we want to use in the replacement string are $3 and $5. Capture group $2, is everything after /cakesite. We don't want to to use that in the replacement string, because $2 includes the space, which is what you're having trouble
with. Capture group $4 gets the space, as well as everything that follows the space. In other words, $4 is a space, plus $5. We don't want that either. We'll use $3 and $5 in the replacement, and insert a + between them. The
plus replaces the space in the original pattern. It will be decoded properly as necessary by IIS.
That works for URLs with a single space. You'd do the same thing with URLs containing more than one space. This is what I mean by "not general". You have to have a dedicated rule, for each number of spaces in the incoming URL.
The best thing to do is to use URLs with no spaces, or encode them and parse them properly, in compliance with RFC 2396. But if you can't do that, these rules might help.