Bug 12875 - Using System.Net.HttpRequest::EndGetRequestStream
Summary: Using System.Net.HttpRequest::EndGetRequestStream
Status: NEEDINFO
Alias: None
Product: Class Libraries
Classification: Mono
Component: System (show other bugs)
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2013-06-25 14:02 UTC by peleyal
Modified: 2013-12-19 15:53 UTC (History)
8 users (show)

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


Attachments

Description peleyal 2013-06-25 14:02:14 UTC
I'm using MonoDevelop 3.1.1 and Mono runtime 3.0.12 (on MAC)

The bug is described in details here -
http://stackoverflow.com/questions/17283314/using-system-net-httprequestendgetrequeststream/17303422?noredirect=1#17303422


System.dll doesn't contain that overload method
EndGetRequestStream(IAsyncResult TransportContext),
it contains only EndGetRequestStream which gets IAsyncResult, but not an
additional TransportContext parameter.

Thanks
Comment 1 Otto G 2013-12-11 07:06:55 UTC
Hi, it seems that the second parameter is only useful under rare circumstances, and certainly not when calling the Google API (http://msdn.microsoft.com/en-us/library/dd383932.aspx -- we may safely assume that the Google APIs do not use Windows authentication).

I have issued a pull request for an implementation that essentially does nothing: https://github.com/mono/mono/pull/834

I hope the pull request was done correctly, as I am new to GitHub.

Whether this primitive solution is acceptable, I do not know, but I can confirm that Mono compiled with the proposed patch can successfully get responses from the Google .NET API, using the dependencies installed by NuGet. (Root certificates need to be installed, and under Linux, LD_LIBRARY_PATH may need to be set appropriately for the native Mono libraries.)

It is not the Google .NET API itself that calls EndGetRequestStream, but one of its dependencies.
Comment 2 peleyal 2013-12-12 12:25:41 UTC
It its the HTTP client library (http://www.nuget.org/packages/Microsoft.Net.Http) which calls that method.
Comment 3 Andres G. Aragoneses 2013-12-13 15:03:42 UTC
The pull request was merged, should this bug be closed as FIXED then?
Comment 4 T.J. Purtell 2013-12-17 02:49:30 UTC
I recently ported all my Http requests off of WebRequest due to its apparent lack of connection pooling.  I have a multi-platform app (ios, android, .net desktop, mac, ...).  I now see this error on my mac.  It prevents the console test version of the app from running and the Xamarin.Mac app from running.  I am using the latest stable Xamarin suite.
Comment 5 T.J. Purtell 2013-12-17 02:50:36 UTC
Unhandled Exception:
System.MissingMethodException: Method not found: 'System.Net.HttpWebRequest.EndGetRequestStream'.
  at System.Net.WebAsyncResult.CB (System.Object unused) [0x00000] in /private/tmp/source/bockbuild-xamarin/profiles/mono-mac-xamarin/build-root/mono-3.2.5/mcs/class/System/System.Net/WebAsyncResult.cs:151
Comment 6 Andres G. Aragoneses 2013-12-17 07:37:07 UTC
TJ you'll need to ask some Xamarin employee when is a new Xamarin release going to include the change that Otto submitted in mono master.
Comment 7 Miguel de Icaza [MSFT] 2013-12-17 20:01:46 UTC
WebRequest and HttpWebRequest are the implementation that powers System.Net.HttpClient, so switching from one to the other only gives you a nicer API to consume, but is still using the same substrate.
Comment 8 Martin Baulig 2013-12-19 15:53:18 UTC
Marked has merged this pull request 8 days ago, can we now close this?

Note You need to log in before you can comment on or make changes to this bug.