Bug 11335 - WebOperationContext.Current.OutgoingRequest.Headers null in OperationContextScope
Summary: WebOperationContext.Current.OutgoingRequest.Headers null in OperationContextS...
Status: RESOLVED FIXED
Alias: None
Product: Class Libraries
Classification: Mono
Component: WCF assemblies ()
Version: 2.10.x
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2013-03-21 17:04 UTC by Matt Clay
Modified: 2016-05-27 15:40 UTC (History)
7 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
This program shows WebOperationContext.Current.OutgoingRequest.Headers is null when it should not be. (2.77 KB, text/plain)
2013-03-21 17:04 UTC, Matt Clay
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Matt Clay 2013-03-21 17:04:30 UTC
Created attachment 3677 [details]
This program shows WebOperationContext.Current.OutgoingRequest.Headers is null when it should not be.

WebOperationContext.Current.OutgoingRequest.Headers is null inside an OperationContextScope on Mono, but under Microsoft .NET it is not.
Comment 2 Jon Goldberger [MSFT] 2014-01-09 17:49:44 UTC
from case 56081:

Our Xamarin Mac application needs to call a WCF REST Web Service that is currently being used by our Windows application. I’ve been able to port over most of the client code (C#) from our windows app but I’ve run into some issues:

We maintain two web service client classes that can access our web service. One uses the REST Starter Kit from Microsoft (which has since been supplanted by .NET 4.5 System.Net.Http classes). Using the System.Net.Http classes I’ve been able to get most of that ported class to compile in Xamarin Studio. We only need to get one of these working for the Xamarin Mac application.

1. HttpClient:

In this version we use HttpContentExtensions.CreateDataContract(), which we used to serialize DataContract decorated classes to HttpContent is not available to us. Also, the .ReadAsDataContract, HttpContentExtensions.Create methods are not available to us either.

And, using the System.Net.Http classes, important classes are missing from the versions available to us in Xamarin Studio: e.g. ObjectContract - which we could use to replace CreateDataContract, etc.

Is there a way for us to convert / reconvert our DataContract class objects or other object to / from HttpContent?

2. System.ServiceModel:

Our other implementation uses System.ServiceModel and our class inherits from ClientBase<IVoicesLicenseProxyService> where IVoicesLicenseProxyService is our main DataContract definition class for the web service. This code compiles and runs - but every call fails with an error 400 (bad request). It looks to me as if the Authorization header is not getting passed (using Fiddler, an HTTP debugging tool) and when the header is being added I notice that the MessageVersion on the OperationContext.Current object is set to ‘Soap” instead of ‘None’ as it is in our Windows version.

I’ve been unable to see how to set the MessageVersion…though I had expected it to be ’None' from the EndPoint definition and the user of WebHttpBinding.

I appreciate any help you can give us on these issues…and modifying the existing WCF REST service is pretty much out of the question.
-------------------------------------------------------------------
Slight correction to what I sent you below: when I wrote “DataContract decorated” I should have written “ServiceContract, OperationContract decorated”.
-------------------------------------------------------------------
I’ve been looking into the problems with System.ServiceModel (# 2 in the
original email) and I have this additional information:

- Our Windows C# code references version 3.0 (System.ServiceModel) and 3.5
(System.ServiceModel.Web) whereas the Xamarin project references version
4.0 for both.

- Looking through Xamarin’s Bug Tracker I found these bugs that may be
related, I can’t tell:
11335
11336
7480

- In our existing Windows code If I comment out the code that adds the
Authorization Header I get the same 400 response and the exact same raw
Request from Fiddler on Windows as I do on the Mac with the Xamarin Mac
application.

Here's the code:

var httpRequestProperty = new HttpRequestMessageProperty();

httpRequestProperty.Headers[System.Net.HttpRequestHeader.Authorization] =
GetAuthorizationCredentials();

OperationContext.Current.OutgoingMessageProperties[HttpRequestMessageProperty.Name]
= httpRequestProperty;

And here's the raw request from both Fiddlers:

GET
http://parsomni-voicessvc.azurewebsites.net/VoicesLicenseProxyService.svc/isaliveHTTP/1.1
Content-Type: application/xml; charset=utf-8
Host: parsomni-voicessvc.azurewebsites.net
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

And here's how a successful request looks (from the Windows app):

GET
http://parsomni-voicessvc.azurewebsites.net/VoicesLicenseProxyService.svc/isaliveHTTP/1.1
Content-Type: application/xml; charset=utf-8
Authorization:
G7GXa/DEA0sSMQFmZ4cA8Ra+G+7H72darJSt+rSwmghXdrB/UouJozcuIuF+U7uV4pusgOAtfXl3WihE9SnX0GipDVM0RI3tFzd2MhS5fJGN3uKXrRNDO1P/4geBA8FUzeWldnyw7QePpO3wgt+3HuvY+s4lSjzS/EAdpgivTPg=
42779810340c389a9e0ed0919a8de543,
Gxr/WSdwn88e8alH8p1f6xbyOz72oBuW3eDrNcs5a6x+eWUvDsNAXS7PtvGtktS5/kXaVK5cXwOJowNREKkN1CBpmZigLq+LQEpOQOuQc8DGOd5exXi8KqywyouElJCk2hVj4hQvjViM+3FVj6kr1U/UeBbS5cXZzo6toSo1EMg=
Host: parsomni-voicessvc.azurewebsites.net
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
-----------------------------------------------------------
I have been unable to get our WCF client code to work in our Xamarin Mac
application. Our client code is ported C# code from our windows application
and the client calls an existing WCF REST service (written in C#). Can you
please help me resolve / work around this issue(s)?

Here is a brief summary and there are a few additional details in the email
thread copied below.

Our client code uses System.ServiceModel and our class inherits from
ClientBase<IVoicesLicenseProxyService>where IVoicesLicenseProxyService is
our main ServiceContract definition class for the web service. This code
compiles and runs - but every call fails with an error 400 (bad request).
The Authorization header is not getting passed and when the header is being
added I notice that the MessageVersion on the OperationContext.Current
object is set to ‘*Soap*” instead of ‘*None*’ as it is in our Windows
client (which is built against .Net 3.5).

I’ve been unable to see how to set the MessageVersion…though I had expected
it to be ’*None*' from the EndPoint definition and the use of
WebHttpBinding.

Here is the code that adds the Authorization header:

var httpRequestProperty = new HttpRequestMessageProperty();
httpRequestProperty.Headers[System.Net.HttpRequestHeader.Authorization]
= GetAuthorizationCredentials();
OperationContext.Current.OutgoingMessageProperties[HttpRequestMessageProperty.Name]
= httpRequestProperty;

This bug is probably related:
https://bugzilla.xamarin.com/show_bug.cgi?id=11335

And possibly this: https://bugzilla.xamarin.com/show_bug.cgi?id=11336
--------------------------------------------------------------
Comment 3 Atsushi Eno 2014-01-10 05:05:30 UTC
fixed [master bf909bc]
Comment 8 vinay 2016-05-27 06:24:36 UTC
Currently we are working on .net framework 3.5, we also facing the same issue working in windows not in Mono.

Can you please tell me which version or which framework this isssue is fixed.
Comment 9 Brendan Zagaeski (Xamarin Team, assistant) 2016-05-27 15:40:42 UTC
@vinay, bugs in the current .NET framework on Windows would be unrelated to the fix for this old bug in Mono, so you would want to raise an issue with the .NET team [1] for further investigation.

[1] https://connect.microsoft.com/VisualStudio/feedback/LoadSubmitFeedbackForm


That said, if you are using Xamarin.Android or Xamarin.iOS on Windows, keep in mind that those particular application types _do_ use the Mono framework on Windows.  If you are hitting a problem on a Xamarin application when using the latest Stable versions of Xamarin, please file a new Xamarin bug report [2] that includes both your detailed version information and a test case that replicates the issue (see also [3]).  Thanks in advance!


[2] https://bugzilla.xamarin.com/newbug
[3] https://kb.xamarin.com/customer/portal/articles/1910343-when-and-how-should-i-file-a-bug-report-



Brendan
Xamarin Customer Support