Re: Code accessing HttpContext.Current

[Louis DeJardin]

Ouch, evil!

Well, one thing you could consider is re-create a pseudo-static property you could access. So if you made a public static IDict<string,object> OwinHttpContext.Current property, and a middleware class which set it going in and cleared it coming out, then your component could use that instead to get the "current" environment.

The tricky part when you implement the Current get/set methods is where to store the value. Thread static breaks down if any of the task work is async - but you might have some of the apis like CallContext.LogicalSetData/LogicalGetData. I believe those values will flow along even if you are async thread-hopping. 

On Tuesday, March 12, 2013 12:50:22 PM UTC-7, Tim Schmidt wrote:

I have a web service that's already written using conventional WebApi under IIS.  I'm trying to make it run under Katana.  The one little problem I'm having is that I have a gateway component deep down (retrieved via IoC) that looks at request headers via HttpContext.Current.  Yes, I know that's not ideal from a testability standpoint, but it was somewhat of a late-in-the-game hack.  But as you could imagine, that's causing me trouble under Katana which doesn't populate HttpContext.Current.

So how can I access headers from down there?

[Tim Schmidt]

N00b question.  Documentation on Owin/Gate/Katana seems scarce at best and the samples are littered with extension methods that either don't exist anymore or that are marked internal.  Is there some guidance on how to create middleware components?

In regards to my original question, I noticed that my ControllerContext (where I'm using my component from) is populated both under asp.net and katana, so I may just use that to call into my component.  Either by passing the components to each method (which seems ugly) or by feeding them into IoC or something... not sure yet.

[Chris R]

The most up to date middleware pattern samples can be found here:

https://github.com/Tratcher/owin-samples/blob/master/MiddlewarePatterns/Startup.cs

There are also a handful of Katana samples on http://aspnet.codeplex.com/.

Let me know if there are major any major gaps.

---

Date: Wed, 13 Mar 2013 13:56:59 -0700
From: t...@schmidthole.com
To: net-http-a...@googlegroups.com
Subject: Re: Code accessing HttpContext.Current

--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstrac...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Louis DeJardin]

That's true, though, there's an awfully short supply of information out there.

[Tim Schmidt]

Thought I had a working implementation but now I'm hitting difficulties because the headers dictionary that Katana uses isn't marked as Serializable.  Argh!

I know this seems icky but it seems like my use case isn't that outlandish.  I have a REST service and I need a component I use makes other REST calls as a result.  There are certain HTTP headers that I need to carry forward.  Is there a better solution?

On Thursday, March 14, 2013 2:14:19 AM UTC-5, Louis DeJardin wrote:

That's true, though, there's an awfully short supply of information out there.

On Wed, Mar 13, 2013 at 8:07 PM, Chris R <trat...@hotmail.com> wrote:

The most up to date middleware pattern samples can be found here:

https://github.com/Tratcher/owin-samples/blob/master/MiddlewarePatterns/Startup.cs

There are also a handful of Katana samples on http://aspnet.codeplex.com/.

Let me know if there are major any major gaps.

---

Date: Wed, 13 Mar 2013 13:56:59 -0700
From: t...@schmidthole.com
To: net-http-a...@googlegroups.com
Subject: Re: Code accessing HttpContext.Current

N00b question.  Documentation on Owin/Gate/Katana seems scarce at best and the samples are littered with extension methods that either don't exist anymore or that are marked internal.  Is there some guidance on how to create middleware components?

In regards to my original question, I noticed that my ControllerContext (where I'm using my component from) is populated both under asp.net and katana, so I may just use that to call into my component.  Either by passing the components to each method (which seems ugly) or by feeding them into IoC or something... not sure yet.

On Tuesday, March 12, 2013 3:01:36 PM UTC-5, Louis DeJardin wrote:

Ouch, evil!

Well, one thing you could consider is re-create a pseudo-static property you could access. So if you made a public static IDict<string,object> OwinHttpContext.Current property, and a middleware class which set it going in and cleared it coming out, then your component could use that instead to get the "current" environment.

The tricky part when you implement the Current get/set methods is where to store the value. Thread static breaks down if any of the task work is async - but you might have some of the apis like CallContext.LogicalSetData/LogicalGetData. I believe those values will flow along even if you are async thread-hopping. 

On Tuesday, March 12, 2013 12:50:22 PM UTC-7, Tim Schmidt wrote:

I have a web service that's already written using conventional WebApi under IIS.  I'm trying to make it run under Katana.  The one little problem I'm having is that I have a gateway component deep down (retrieved via IoC) that looks at request headers via HttpContext.Current.  Yes, I know that's not ideal from a testability standpoint, but it was somewhat of a late-in-the-game hack.  But as you could imagine, that's causing me trouble under Katana which doesn't populate HttpContext.Current.

So how can I access headers from down there?

--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstractions+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups ".NET HTTP Abstractions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-http-abstractions+unsub...@googlegroups.com.

[Tim Schmidt]

I ended up solving this by creating a context object that captures the headers I need.  Since I'm using WebApi, I always got a correctly populated ControllerContext either way.  So I made an action filter that looks at that, populates one of my context objects, and sets a static using the method you said before (CallContext.SetLogicalData).  That way my backend component, regardless of the environment I'm running in, can get at the context for the current request.

[Tim Schmidt]

Just to followup from the call on performance, there's definitely some contention going on somewhere.  Upping the ServicePointManager stuff (either in config or code) didn't seem to matter.  I'm definitely not ruling out my code, but it's odd that I don't see any issues under IIS.  Here are the perf numbers I see on my local dev box:

Katana

  - 25 threads, 50 times: 95.89 sec

  - 15 threads, 50 times: 90.56 sec

IIS

  - 25 threads, 50 times: 37.20 sec

  - 15 threads, 50 times: 25.20 sec

When I ran 15x50 under Katana, I definitely saw bursts of 15 go through at a time, that's what made it seem like contention.  I'm not sure where I should go from here.  I may try doing some profiling to see if I can figure anything out.