+972 52-548-6969
Hunt the bug
time to read 1 min | 180 words
The following code will throw under certain circumstances, what are they?
public class Global : HttpApplication { public void Application_Start(object sender, EventArgs e) { HttpUtility.UrlEncode("Error inside!"); } }
Hint, the exception will not be raised because of transient conditions such as low memory.
What are the conditions in which it would throw, and why?
Hint #2, I had to write my own (well, take the one from Mono and modify it) HttpUtility to avoid this bug.
ARGH!
Comments
I guess it has to do with the new HttpEncoder support. I can be disabled by setting Response.DisableCustomHttpEncoder but that is not available in application start. You could have used HttpEncoder.Default however.
I'm guessing that HttpUtility underneath requires an HttpContext and that might not be present at Application_Start.
Yep, starting .NET 4 HttpUtility requires a HttpContext /HttpResponse wich is not yet available at the time of Application_Start with IIS7 in integrated mode. I guess the stack trace looks like:
[HttpException (0x80004005): Response is not available in this context.]
System.Web.HttpContext.get_Response() +8753496
System.Web.Util.HttpEncoder.get_Current() +39
System.Web.HttpUtility.UrlEncodeToBytes(String str, Encoding e) +31
System.Web.HttpUtility.UrlEncode(String str) +41
Global.Application_Start(Object sender, EventArgs e)
This means that the context is available but it is a fake one - getting the response throws. My workaround that I posted is still valid ;-)
There has been some changes in .NET 4 which introduced this bug. I hit it when we switched our solution to VS2010. So as it's actually forgetting to check HttpContext.Current null values before using it, we hacked this by assigning a mock HttpContext around it.
Sebastien
Comment preview