Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
When calling the same service over HTTPS / SSL a response is received, but the response content is empty (0 bytes)
## Steps to Reproduce:
1. Open the attached Test Case.
2. Make sure that all NuGet packages are restored.
3. Set SOAPErrorDemo.Droid as the Startup Project.
4. Run the project on an android device / emulator.
5. Toggle SSL and press the Get Results button.
6. Observe the output "Zero-length content stream" (found at SOAPErrorDemo.GetAppointmentsService:80)
## Actual Results:
ReadAsStreamAsync() returns a 0 length stream.
## Expected Results:
Return a content stream that is not 0 length.
## Build Date & Platform:
## Additional Information:
There is one subtle complexity that may or may not be relevant - the SSL certificate is self-generated, so System.Net.ServicePointManager.ServerCertificateValidationCallback was used to tell the app to trust the certificate.
Test Case is private.
I have tried this issue but not able to reproduce it. I performed same steps as given in description. I also added debugger at ReadAsStreamAsync() method and observed that this method is returning content having length of 2296.
Screencast regarding same is : http://screencast.com/t/frxWYTvdi
Environment Info :
=== Xamarin Studio ===
Version 5.0.1 (build 3)
Installation UUID: 1151d3d9-29c1-4339-b53c-a54856b47901
Mono 3.4.0 ((no/c3fc3ba)
GTK+ 2.24.23 (Raleigh theme)
Package version: 304000204
=== Apple Developer Tools ===
Xcode 5.1 (5084)
=== Xamarin.iOS ===
Version: 22.214.171.124 (Business Edition)
Build date: 2014-05-19 19:10:29-0400
=== Xamarin.Android ===
Version: 4.12.4 (Trial Edition)
Android SDK: /Users/shruti/Desktop/android-sdk-macosx
Supported Android versions:
2.1 (API level 7)
2.2 (API level 8)
2.3 (API level 10)
3.1 (API level 12)
3.2 (API level 13)
4.0 (API level 14)
4.0.3 (API level 15)
4.1 (API level 16)
4.2 (API level 17)
4.3 (API level 18)
4.4 (API level 19)
Java SDK: /usr
java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)
=== Xamarin.Mac ===
Xamarin.Mac: Not Installed
=== Build Information ===
Release ID: 500010003
Git revision: f94ee866936d25105704eb63728ad5a981eda0a4
Build date: 2014-06-04 12:19:12-04
Xamarin addins: 1a6044e8321ea07e03a56b5381951686c82fed8b
=== Operating System ===
Mac OS X 10.9.2
Darwin Shrutis-Mac-mini.local 13.1.0 Darwin Kernel Version 13.1.0
Thu Jan 16 19:40:37 PST 2014
Please let me know If I missed anything to reproduce this issue.
I am using Visual Studio not Xamarin Studio.
However, I have now tried debugging with Xamarin Studio, and I can sometimes (2 out of 3 times) get a response with 'short wait' selected. I can never get a response when 'long wait' is selected.
Could you please retry with an additional step between 5 and 6 to 'Toggle 'Long Wait''? This will call a web service that is slower to respond (typically between 10 and 20s) and will return a larger payload.
Also could you please attempt to reproduce when deploying / debugging from within Visual Studio?
@Jim, Thanks for providing more detail. It help us to reproduce the issue.
I have tried this issue on Visual Studio. I have put breakpoints and debug the application with both cases
Short Wait and Long Wait. I observed that When first I debug the application with Short Wait, it is working fine as per expectations. But When debug it with Long Wait, giving 0 length output.
Screencast regarding same : http://www.screencast.com/t/4aapAxIQ
I again debug the app with Short wait after debugging with Long Wait. Here I observed that ContentStream contains no content (0 length).
Build Output Log : https://gist.github.com/saurabh360/d23422508cb17331ffeb
Adb Logcat : https://gist.github.com/Mohit-Kheterpal/c0760e498acda8cb91ac
Environment Info :
Microsoft Visual Studio Professional 2013
Xamarin.Android 126.96.36.199 (b5dc5ce91305e19de51d71a1122c109719c4bc34)
Created attachment 7214 [details]
The issue is reproducible with desktop mono as well. Attached is a distilled destkop case that reproduces it reliably for me with the tip of Mono master.
Martin, assigning it to you since it appears to be a race condition in how WebConnection reads the SSL stream. Marek Safar determined that putting a sleep in WebConnection.BeginRead allows him to get the data from the stream.
Good news! I finally figure out what's causing this and got a test case in my new async web-test suite.
The bug actually has nothing at all to do with SSL - but the circumstances that you need to trigger this are so obscure that they may never happen without SSL.
Here's my test case:
If you look at that Write() method, removing the AutoFlush, any of the Thread.Sleep()'s, joining the writer.Write()'s or using a chunk-size that does not start with a zero will make this bug go away.
The web server needs to send a chunk-size that starts with a trailing zero (which is valid) and the stream must be buffered in a way that we read all the headers up to and including this zero.
In my test case, the server sends:
"HTTP/1.1 200 OK\r\nTransfer-Encoding: chunked:\r\n\r\n04\r\nAAAA\r\n0\r\n\r\n\r\n"
and the first Read() returns "HTTP/1.1 200 OK\r\nTransfer-Encoding: chunked:\r\n\r\n0", so the ChunkStream gets constructed with a single byte - the training "0" - which is incorrectly considers as an empty chunk.
My guess is that SSL makes this more likely to happen because it seems to be using smaller packet sizes. Using a real Apache web server without SSL and it's always sending the first 4000+ bytes of a long response.
As a work-around, if you have access to that server, turn off chunked encoding or make it send the chunk size without a trailing zero. Adding some random HTTP headers could also work if you're lucky.
I should have a real fix tomorrow.
Fixed; mono/master 288489d and mono-3.6.0-branch 80b4f74.