Bug 12875 - Using System.Net.HttpRequest::EndGetRequestStream
Summary: Using System.Net.HttpRequest::EndGetRequestStream
Status: RESOLVED NORESPONSE
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: 2018-03-13 11:07 UTC (History)
8 users (show)

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

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 NORESPONSE

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?
Comment 9 Marek Safar 2018-03-13 11:07:28 UTC
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and reopen the bug report.

Thank you!