By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,117 Members | 1,714 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,117 IT Pros & Developers. It's quick & easy.

Url encoding issue; + v. %2B

P: n/a
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 the
file naming rules of the Windows file system. Because spaces are plus (+)
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 using
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; the
Url value that I get through Request.RawUrl appears with the %2B translated,
as follows...

http://yadda/getfile/test+test+test.txt

This means that I can't distinguish between plus signs and spaces. When I
decode, I get;

http://yadda/getfile/test test test.txt

Which makes it impossible for me to locate the file the user has requested.

I've tested this many times, refreshing, viewing the results in trace.axd,
and the problem is very consistent. I can see the %2B in the Url bar, but
it's being decoded before the value is stored in Request.RawUrl. None of
the other header variables (as perused in trace.axd) show the %2B either.

I haven't isolated the location of the problem yet; it's somewhere between
the Internet Explorer Url bar and the start of execution of my HttpModule.
The problem might be IE6, or IIS, or .NET; I'm hopeful that someone already
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 about a
solution, so ideas are welcome. Clearly, I'd like to avoid my own
additional encoding scheme if I can avoid it...

Many thanks.

/// M


Nov 19 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
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 .aspx
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:OH**************@TK2MSFTNGP10.phx.gbl...
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 the
file naming rules of the Windows file system. Because spaces are plus (+)
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 using 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; the
Url value that I get through Request.RawUrl appears with the %2B translated, as follows...

http://yadda/getfile/test+test+test.txt

This means that I can't distinguish between plus signs and spaces. When I
decode, I get;

http://yadda/getfile/test test test.txt

Which makes it impossible for me to locate the file the user has requested.
I've tested this many times, refreshing, viewing the results in trace.axd,
and the problem is very consistent. I can see the %2B in the Url bar, but
it's being decoded before the value is stored in Request.RawUrl. None of
the other header variables (as perused in trace.axd) show the %2B either.

I haven't isolated the location of the problem yet; it's somewhere between
the Internet Explorer Url bar and the start of execution of my HttpModule.
The problem might be IE6, or IIS, or .NET; I'm hopeful that someone already 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 about a solution, so ideas are welcome. Clearly, I'd like to avoid my own
additional encoding scheme if I can avoid it...

Many thanks.

/// M

Nov 19 '05 #2

P: n/a
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:OB**************@TK2MSFTNGP15.phx.gbl...
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 ..aspx 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:OH**************@TK2MSFTNGP10.phx.gbl...
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 the file naming rules of the Windows file system. Because spaces are plus (+) 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 using
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; the Url value that I get through Request.RawUrl appears with the %2B

translated,
as follows...

http://yadda/getfile/test+test+test.txt

This means that I can't distinguish between plus signs and spaces. When I decode, I get;

http://yadda/getfile/test test test.txt

Which makes it impossible for me to locate the file the user has

requested.

I've tested this many times, refreshing, viewing the results in trace.axd, and the problem is very consistent. I can see the %2B in the Url bar, but it's being decoded before the value is stored in Request.RawUrl. None of the other header variables (as perused in trace.axd) show the %2B either.
I haven't isolated the location of the problem yet; it's somewhere between the Internet Explorer Url bar and the start of execution of my HttpModule. The problem might be IE6, or IIS, or .NET; I'm hopeful that someone

already
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

about a
solution, so ideas are welcome. Clearly, I'd like to avoid my own
additional encoding scheme if I can avoid it...

Many thanks.

/// M


Nov 19 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.