Bug 20359 - System.Net.WebClient.UploadValuesTaskAsync doesn't set Content-Type
Summary: System.Net.WebClient.UploadValuesTaskAsync doesn't set Content-Type
Alias: None
Product: Class Libraries
Classification: Mono
Component: System ()
Version: master
Hardware: Other Other
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2014-06-04 19:23 UTC by Benjamin Herr
Modified: 2014-09-23 13:12 UTC (History)
3 users (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 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:

Description Benjamin Herr 2014-06-04 19:23:07 UTC
Description of Problem: System.Net.WebClient.UploadValues sets the request's content type to application/x-www-form-urlencoded. UploadValuesTaskAsync (all overloads) tries to do that too, but it actually seems to create the request object first, before setting WebClient.Header["Content-Type"], which is only taken into account when creating the request object, so it's not actually set on the request object. (If another request is made with the same client object, the content type header is then set.)

Steps to reproduce the problem:
1. Do a POST request with UploadValuesTaskAsync (eg. new System.Net.WebClient().UploadValuesTaskAsync("http://localhost:8000", new System.Collections.Specialized.NameValueCollection()).Wait(); )
2. Observe the HTTP request headers (eg. nc -l -p 8000)

Actual Results: No content type is sent.

Expected Results: Content type is set to application/x-www-form-urlencoded

How often does this happen? Every time.

Additional Information:
Comment 1 Martin Baulig 2014-08-11 09:48:48 UTC
Have patch, will commit shortly.
Comment 2 Martin Baulig 2014-08-25 12:16:22 UTC
Comment 3 Ram Chandra 2014-09-23 13:12:24 UTC
I have checked this issue and I am able to reproduce this issue with following builds:

Screencast: http://www.screencast.com/t/lglh4CwADJyn

To verify this issue, I have checked this issue with following builds:

Mac OS X 10.9.5
Xamarin Studio : 5.5 (build 205)
Mono 3.10.0 ((detached/ac51002)
GTK+ 2.24.23 (Raleigh theme)
=== Build Information ===
Release ID: 505000205
Git revision: 589aaa0ca48859c46adfa71a30dc4a1cd37c5162
Build date: 2014-09-23 08:41:44-04
Xamarin addins: c31fea2f959659225466adef1c0793a8d7eebcef

Steps I followed:

1. Open a console application.
2. Write the following class in "Program.cs"
    class Foo
        public Task<byte[]> SendMessage(string url, NameValueCollection collection)
            WebClient obj = new WebClient();
            return obj.UploadValuesTaskAsync(url, collection);          

3. Write the following code in main() method.
            Foo obj = new Foo();
            WebClient obj1 = new WebClient();
            NameValueCollection test2 = new NameValueCollection();
            Task<byte[]> test = obj.SendMessage("https://www.google.com/", new NameValueCollection());

4. Set the breakpoint on the ending curly braces of Foo() method.
5. Build and debug the application.
6. When breakpoint hits, observe the values of object obj in SendMessage() method.

I observed that now "UploadValuesTaskAsync" method set the content type to "application/x-www-form-urlencoded".

Screencast: http://www.screencast.com/t/DL6Xatfs

This issue has been fixed. Hence, I am closing this issue.