Bug 19119 - [HttpWebRequest]: Correctly resend the body when using authentication and POST
Summary: [HttpWebRequest]: Correctly resend the body when using authentication and POST
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: 7.2.1
Hardware: PC Windows
: Highest blocker
Target Milestone: 7.2.1
Assignee: Bugzilla
: 19068 ()
Depends on:
Reported: 2014-04-17 09:38 UTC by Mikkel
Modified: 2014-06-03 13:30 UTC (History)
9 users (show)

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

Hotfix (1.24 MB, application/x-msdownload)
2014-04-17 17:02 UTC, Martin Baulig
System.dll.mdb (578.33 KB, application/octet-stream)
2014-04-17 17:02 UTC, Martin Baulig

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 Mikkel 2014-04-17 09:38:43 UTC
After upgrading from iOS 7.2.0 to 7.2.1, calling a standard soap WebService (using HTTP Basic Authentication) in an iOS iPad project (using standard NetworkCredentials), the WebService call hangs for a while until finally timing out.

Downgrading to iOS 7.2.1 seems to solve the problem.

I haven't chased down the specifics of the problem, nor have I experienced with disabling authentication to see if this is causing the issue.

I guess I could try and create a test solution, but haven't had the time to do so.

Comment 1 Sebastien Pouliot 2014-04-17 11:38:19 UTC
> Downgrading to iOS 7.2.1 seems to solve the problem.

You likely meant downgrading to 7.2.0 right ?

Is it possible your web service is using NTLM for authentication ?

Any other details would be useful. Thanks.
Comment 2 Martin Baulig 2014-04-17 12:03:58 UTC
This is not related to NTLM.  Closing as duplicate of #19068.
Comment 3 Mikkel 2014-04-17 12:55:15 UTC
Needless to say, yes, I meant downgrade to 7.2.0 - obviously that was a typo. And yes, I am 100% sure that I meant HTTP Basic Authentication - not NTLM.

@Martin: Why am I restricted from viewing #19068, what are the details of this bug, and what is being done about it - when is it possible to upgrade to 7.2.1+?
Comment 4 Martin Baulig 2014-04-17 13:01:12 UTC
#19068 was originally filed against a proprietary component, that's why it's private.  But let's keep the technical details in here, no need to keep them secret.

>>>> My comment 14 <<<<
Possible fix:

always execute the
                                bodyBuffer = writeStream.WriteBuffer;
                                bodyBufferLength =

inside this "if" block, ie. remove the conditional, keep the code inside it:


Will do some more testing and have a patch ready shortly.

>>> My comment 15 <<<<<

This fix is not complete yet, we probably need to do the
writeStream.WriteBufferLength >= 0 check and we may have to not do it for the
NTLM Challenge.

If you look a few lines down, there's this block:

            bodyBuffer = null;
            if (throwMe == null) {
                bool b = false;
                int c = (int) code;
                if (allowAutoRedirect && c >= 300) {
                    b = Redirect (result, code, webResponse);
                    if (InternalAllowBuffering && writeStream.WriteBufferLength
> 0) {
                        bodyBuffer = writeStream.WriteBuffer;
                        bodyBufferLength = writeStream.WriteBufferLength;
                    if (b && !unsafe_auth_blah) {
                        auth_state.Reset ();
                        proxy_auth_state.Reset ();

                if (resp != null && c >= 300 && c != 304)
                    resp.ReadAll ();

                return b;

which resets the write buffer when we're redirecting.

We need to do the same when using authentication.
>>>>>> <<<<<<<
Comment 5 Martin Baulig 2014-04-17 13:03:10 UTC
My recent web stack changes changed the way how we're handling the body of a POST request when redirecting.  Unfortunately, this breaks authentications (which are a "special" kind of redirects).
Comment 6 Martin Baulig 2014-04-17 13:03:49 UTC
*** Bug 18799 has been marked as a duplicate of this bug. ***
Comment 7 Martin Baulig 2014-04-17 13:05:13 UTC
*** Bug 19068 has been marked as a duplicate of this bug. ***
Comment 8 Martin Baulig 2014-04-17 13:06:06 UTC
Ignore #18799, that was an accident.
Comment 9 Mikkel 2014-04-17 13:26:26 UTC
So is this a duplicate or what, this is getting a bit confusing... Is it being investigated, do you need more info or not?
Comment 10 Sebastien Pouliot 2014-04-17 13:33:47 UTC
@Mikkel Being a duplicate does not mean the other bug report is fixed (just that it was filed).

It's also hard to be 100% sure if two bugs are identical (or just similar) unless we have very specific information (or test cases), which is why your information were useful. 

We'll ask you specifically if we need more information. Thanks.
Comment 11 Martin Baulig 2014-04-17 13:35:19 UTC
Sorry for the confusion.  I swapped the two bugs to keep all the relevant information in here, where it's public.  So the other bug is now a duplicate of this one.
Comment 12 Mikkel 2014-04-17 13:41:49 UTC
Thx Sebastian, I was just curious as to when and if this could be fixed, so we can upgrade and get all the other great and long-awaited bug fixes in that release.
Comment 14 Martin Baulig 2014-04-17 14:26:56 UTC
Possible fix:

However, this may break NTLM, so I need to test that before we can merge this into master.
Comment 16 Mikkel 2014-04-17 16:47:22 UTC
@Martin: Thanks for the quick fix, looking forward to testing it - do we have to wait for the next release (if so, when will it be released?) or how can we get it?
Comment 17 Martin Baulig 2014-04-17 17:02:01 UTC
Created attachment 6606 [details]

Put this into /Developer/MonoTouch/usr/lib/mono/2.1/System.dll
Comment 18 Martin Baulig 2014-04-17 17:02:37 UTC
Created attachment 6607 [details]
Comment 19 Martin Baulig 2014-04-17 17:03:43 UTC
Hey Mikkel,

I just created a hotfix for you :-)

Could you please put the attached System.dll and System.dll.mdb into /Developer/MonoTouch/usr/lib/mono/2.1/ and check whether this fixes the problem for you?

Comment 20 Mikkel 2014-04-17 17:09:59 UTC
Thanks again - I sure will - tomorrow :-).
Comment 21 Sebastien Pouliot 2014-04-18 15:09:31 UTC
The fixes were backported in 773c77cd82558c87872108b96b3226e3d7325dd2.

@Mikkel I'm closing the bug (so it can be verified by QA) but we're still looking forward your confirmation that this works properly. Thanks!
Comment 22 Mikkel 2014-04-19 03:51:16 UTC
First of all, I can re-confirm that doesn't work with WebService and HTTP Basic Authentication. When debugging on the webserver, the WebService call goes through and authenticating is (apparently) completed normally, but the second part of the call, requesting or posting data, times out as mentioned earlier.

Secondly, I'm happy to confirm that the hotfix solves this authentication/timeout problem, however I think the overall speed of authenticating and communicating with the WebService is slower than normal - could there be an issue there?
Comment 24 narayanp 2014-06-03 09:44:31 UTC
I have tried to reproduce this issue with X.iOS 7.2.1-25 using iOS sample HttpWebRequest. but I am not able to reproduce this issue.
Could you please provide me any test project or some steps so that I can also reproduce it?

Checked with
X.S 4.2.5(Build 0)
X.iOS 7.2.1-25
Comment 25 Mikkel 2014-06-03 10:35:22 UTC
Hi narayanp,

Sorry, that's not possible.

Why would you want to reproduce it, when it has already been fixed, confirmed and closed??

Comment 26 Martin Baulig 2014-06-03 13:30:26 UTC
This bug was previously in the VERIFIED state, putting it back there.