Change CallContext to AsyncLocal

[pengweiqhca]

Refactoring HttpRequestMessageProvider, change CallContext to AsyncLocal.

System.Security.SecurityException : Type System.Runtime.Remoting.ObjRef and the types derived from it (such as System.Runtime.Remoting.ObjRef) are not permitted to be deserialized at this security level.

Server stack trace: 
   at System.Runtime.Serialization.FormatterServices.CheckTypeSecurity(Type t, TypeFilterLevel securityLevel)
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.CheckSecurity(ParseRecord pr)
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ParseObject(ParseRecord pr)
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Parse(ParseRecord pr)
   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)
   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryHeaderEnum binaryHeaderEnum)
   at System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
   at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
   at System.Runtime.Remoting.Channels.CoreChannel.DeserializeBinaryRequestMessage(String objectUri, Stream inputStream, Boolean bStrictBinding, TypeFilterLevel securityLevel)
   at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at ......

[tillig]

I don't understand what you're asking for here. The call stack doesn't appear to have any Autofac components and there's not enough information here to understand why you'd want to change the HttpRequestMessageProvider. I see there's a security related exception, but I don't understand the conditions under which that would occur. Please provide more information so we can understand better the problem and ensure the fix is correct (and that it won't get regressed later).

[pengweiqhca]

I don't understand what you're asking for here. The call stack doesn't appear to have any Autofac components and there's not enough information here to understand why you'd want to change the HttpRequestMessageProvider. I see there's a security related exception, but I don't understand the conditions under which that would occur. Please provide more information so we can understand better the problem and ensure the fix is correct (and that it won't get regressed later).

Because, I call builder.RegisterHttpRequestMessage(GlobalConfiguration.Configuration) in Startup.cs, and call a remoting service in webapi.

If I delete builder.RegisterHttpRequestMessage(GlobalConfiguration.Configuration) or refactoring HttpRequestMessageProvider use AsyncLocal, I will not get a exception.

[tillig]

Remoting? 😱 I see. OK, that wasn't clear.

Yeah, we can probably do that. I'm not sure how quickly one of us can do it, but we'd take a PR. We'd also need to make sure it's tested out before we release to make sure the change doesn't break folks. Things don't change much in here and that could be a subtle breaking thing.

[tillig]

Is there a way to do a local build of Autofac.WebApi so you can test that would fix it? I want to make sure we aren't changing something that won't actually end up helping. Remoting and security context stuff can be a little tricky and changing one thing might reveal the problem to just be something else underneath it.

[pengweiqhca]

Is there a way to do a local build of Autofac.WebApi so you can test that would fix it? I want to make sure we aren't changing something that won't actually end up helping. Remoting and security context stuff can be a little tricky and changing one thing might reveal the problem to just be something else underneath it.

I refactoring HttpRequestMessageProvider, and it work well.

[pulkit7sharma]

@pengweiqhca / @tillig

I believe this change may have introduced a breaking issue, though I’m not sure how. Our Web APIs have been running fine on version 6.0.1, but after upgrading to 6.1.0 we started losing request IDs (the header stored in .NET Framework’s CallContext) in our logs immediately after executing RateLimiters (IAutofacActionFilters). When we remove those filters, the request IDs flow correctly and all log lines are captured. Is there a way to address or work around this issue?

[tillig]

@pulkit7sharma
There's not enough to go on to say what the root cause of the issue is that you're seeing. Maybe it's this, maybe it's something else. The only way to tell is with a minimal repro. ("Minimal" is super key here. Not one single class, interface, filter, or line of code that doesn't contribute to showing the problem.)

Once you have that and can 100% illustrate the problem, if you still conclude it's use of AsyncLocal here, open a new issue and include the repro.

[pulkit7sharma]

@tillig I was able to reproduce this issue and have opened a new ticket. Could you please take a look?
#72

[tillig]

I follow new issues and get to them as time permits. If other community members get there first, great. However, there isn't "an Autofac team" and there's no SLA on responses, so please be patient.