HttpContext vs. OperationContext in DataService with HTTP headers

Question

I have a WCF DataService (v5.2) that overrides OnStartProcessingRequest(ProcessRequestArgs args). I want to add some headers to the response (in this method that I assume is the right place?). I first tried this:

args.OperationContext.ResponseHeaders.Add(...)

That didn't work. I then tried this:

OperationContext.Current.OutgoingMessageHeaders.Add(...)

That didn't work. I tried adding a new OperationContextScope on that sucker. It still failed. At last I tried this:

HttpContext.Current.Response.AddHeader(...);

That option worked! (By "work" I mean that it actually showed up in the response to the the client.) Why didn't the first two options work?

After reading further on the web I discovered that

WebOperationContext.Current.OutgoingResponse.Headers.Add(...)

also works. Why on earth do we have four current contexts inside this method? How is a person to know which one to use (at runtime)? Which ones are valid in my [WebGet] methods? Which ones are valid in my [QueryInterceptor] methods? Which context is guaranteed to have the right request headers? (I've been using args.OperationContext for that presently.)

Shostakovich

Answer 1

Don't know about ProcessRequestArgs.OperationContext.ResponseHeaders, but I think I can explain why OperationContext.Current.OutgoingMessageHeaders didn't work: the "headers" there are SOAP headers (presumably ignored for non-SOAP services), not HTTP headers. In the other two cases (HttpContext.Current.Response.AddHeader andWebOperationContext.Current.OutgoingResponse.Headers) notice the "Http" and "Web" in the names to indicate that you're doing something HTTP-specific, i.e. adding HTTP headers.

By the way:

• OperationContext - regular WCF operation context
• WebOperationContext - REST/HTTP extensions for WCF operation context
• HttpContext - compatibility with ASP.NET hosting model, only works when using ASP.NET compat mode (not when self-hosted, etc), see http://blogs.msdn.com/b/wenlong/archive/2006/01/23/516041.aspx

Backbreaking