Bug 17727 - HttpClient request-method POST changed to GET
Summary: HttpClient request-method POST changed to GET
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: 7.0.6.x
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Martin Baulig
: 17656 ()
Depends on:
Reported: 2014-02-12 10:45 UTC by Allie Miller
Modified: 2014-02-13 15:13 UTC (History)
1 user (show)

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 Developer Community or GitHub 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:

Description Allie Miller 2014-02-12 10:45:42 UTC
After the recent update to Xamarin.iOS 7.0.6, the attached sample changes the Post method to GET.

To reproduce:
Call the XamarinHttpPostBug.Demonstrate()

In the SetRequestData-function, the Request object enters with method "POST", but leaves with method "GET".

Downgrading back to Xamarin.iOS resolves this issue.
Comment 2 Martin Baulig 2014-02-13 14:12:13 UTC
This is by design and we won't change it unless very strong arguments are provided.

We issue change any request to "GET" on a 301 Moved Permanently and 302 Found, which is what most user agents do according the the HTTP 1.1 spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3):

10.3.3 302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request.  However, most
      existing user agent implementations treat 302 as if it were a 303
      response, performing a GET on the Location field-value regardless
      of the original request method. The status codes 303 and 307 have
      been added for servers that wish to make unambiguously clear which
      kind of reaction is expected of the client.

If you want to perform a POST on the redirected uri, then your server needs to return a 307 Temporary Redirect.
Comment 3 Martin Baulig 2014-02-13 14:53:17 UTC
The correct way of dealing with a server that returns a HTTP 302 on a URL that you want to post to is to perform a HEAD first with auto-redirect disabled:

		var request = (HttpWebRequest)WebRequest.Create (url);
		request.ProtocolVersion = HttpVersion.Version11;
		request.Method = "HEAD";
		request.AllowAutoRedirect = false;

		var response = (HttpWebResponse)request.GetResponse ();
		Console.WriteLine ("HEAD: {0}", response.StatusCode);
		if (response.StatusCode == HttpStatusCode.Found) {
			var location = response.Headers ["Location"];
			Console.WriteLine ("REDIRECT TO: {0}", location);
Comment 4 Martin Baulig 2014-02-13 15:13:15 UTC
*** Bug 17656 has been marked as a duplicate of this bug. ***