So, being curious, I went digging.
I think it's been (mis?)said since the dawn of ASP.NET that it wasn't safe to use TLS because multiple threads could service your request. I think it's more correct to state that you should only use TLS for data you know will be bound to that thread and the lifecycle of that thread.
My basis for this is doing a little digging with Reflector and the System.Web dll. If you look, HttpContext.Current is a wrapper to CallContext:
Code:
public static HttpContext get_Current()
{
return (CallContext.GetData("HttpContext") as HttpContext);
}
CallContext.GetData looks like this:
Code:
public static object GetData(string name)
{
object obj1 = CallContext.LogicalGetData(name);
if (obj1 == null)
{
return CallContext.IllogicalGetData(name);
}
return obj1;
}
LogicalGetData:
Code:
private static object LogicalGetData(string name)
{
return Thread.CurrentThread.GetLogicalCallContext().GetData(name);
}
Thread's GetData:
Code:
public object GetData(string name)
{
return this.Datastore[name];
}
So, in summary, I think that Microsoft relies on TLS to handle HttpContext.Current (unless I'm reading this wrong). So, it would seem it's save to use TLS.
That said, I personally still like to use CallContext as my entry point for most things... call me new-fashioned I guess.