Further update;
In my particular application I've been able to solve this problem. In this
particular case, I manufacture all of the Urls that the user accesses using
Url rewriting, and as a result I can eliminate the problematic "space to +"
encoding behavior.
// original Windows filename I need to embed in the Url
string szUrl = "test+test test.txt";
// encode the Url
szUrl = Server.Encode (szUrl); // creates test%2Btest+test
// substitute %20 for + as encoded spaces
szUrl = szUrl.Replace ("+", "%20"); // creates test%2Btest%20test
// finish Url
szUrl = "http://mysite.com/getfile/" + szUrl;
// set link
hlFile.Hyperlink = szUrl;
In this case the HttpModule gets the Url as;
http://mysite.com/getfile/test+test test.txt
HTH anyone who finds themselves facing the same issue.
/// M
"MWells" <outbound__at_sygnal.com> wrote in message
news:OBNH6Ou#EHA.3924@TK2MSFTNGP15.phx.gbl...[color=blue]
> Update; for anyone interested, the Url decoding problem is definately
> occurring in the HttpModule. I've setup an HttpModule that does nothing
> but;
>
> Trace.Write (HttpContext.Current.Request.RawUrl);
>
> When entering a Url into MSIE like;
>
>
http://mysite/test+test%2Btest/testing.aspx
>
> The HttpModule gets;
>
>
http://mysite/test+test+test/testing.aspx
>
> I've turned off IIS wildcard mapping for the test, eliminated most all of
> the other elements I can think of. If I do this same test to a normal[/color]
..aspx[color=blue]
> page without the HttpModule, I get the properly decoded Url;
>
>
http://mysite/test test+test/testing.aspx
>
> Does anyone have any idea why this is happening, or where to go from here?
> Is there a defect submission procedure for this kind of anomaly?
>
> Thanks again,
>
> /// M
>
>
>
> "MWells" <outbound__at_sygnal.com> wrote in message
> news:OHFkzTV#EHA.2272@TK2MSFTNGP10.phx.gbl...[color=green]
> > I've encountered an interesting issue regarding Url encoding that I'm
> > hopeful someone can shed some light on.
> >
> > I have some vanity Url's that have to contain filename content, using[/color][/color]
the[color=blue][color=green]
> > file naming rules of the Windows file system. Because spaces are plus[/color][/color]
(+)[color=blue][color=green]
> > signs are permitted in Windows filenames, I might have a file called;
> >
> > "test+test test.txt"
> >
> > And the vanity Url that references it might be something like;
> >
> >
http://yadda/getfile/test+test test.txt
> >
> > To avoid Url problems, I encode the filename portion of the vanity Url[/color]
> using[color=green]
> > Server.UrlEncode () and I get...
> >
> >
http://yadda/getfile/test%2Btest+test.txt
> >
> > Looking good so far, but in my HttpModule I run into a serious issue;[/color][/color]
the[color=blue][color=green]
> > Url value that I get through Request.RawUrl appears with the %2B[/color]
> translated,[color=green]
> > as follows...
> >
> >
http://yadda/getfile/test+test+test.txt
> >
> > This means that I can't distinguish between plus signs and spaces. When[/color][/color]
I[color=blue][color=green]
> > decode, I get;
> >
> >
http://yadda/getfile/test test test.txt
> >
> > Which makes it impossible for me to locate the file the user has[/color]
> requested.[color=green]
> >
> > I've tested this many times, refreshing, viewing the results in[/color][/color]
trace.axd,[color=blue][color=green]
> > and the problem is very consistent. I can see the %2B in the Url bar,[/color][/color]
but[color=blue][color=green]
> > it's being decoded before the value is stored in Request.RawUrl. None[/color][/color]
of[color=blue][color=green]
> > the other header variables (as perused in trace.axd) show the %2B[/color][/color]
either.[color=blue][color=green]
> >
> > I haven't isolated the location of the problem yet; it's somewhere[/color][/color]
between[color=blue][color=green]
> > the Internet Explorer Url bar and the start of execution of my[/color][/color]
HttpModule.[color=blue][color=green]
> > The problem might be IE6, or IIS, or .NET; I'm hopeful that someone[/color]
> already[color=green]
> > knows the answer before I have to put on the hardhat and go spelunking.
> >
> > Also while I'd like to understand it, I'm more immediately concerned[/color][/color]
about[color=blue]
> a[color=green]
> > solution, so ideas are welcome. Clearly, I'd like to avoid my own
> > additional encoding scheme if I can avoid it...
> >
> > Many thanks.
> >
> > /// M
> >
> >
> >
> >[/color]
>
>[/color]
