ProtocolException with iOS .NET 6.0 Application: The number of bytes available is inconsistent with the HTTP Content-Length header. #4903
Comments
|
From @chamons on Tue, 06 Sep 2022 15:07:56 GMT Given all of the assemblies in the stack trace are BCL (Base Class Library), in particular System.ServiceModel.*, I believe this should be looked at by the dotnet folks first. |
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
|
I think this belongs in dotnet/wcf |
|
Note this works fine in a .NET 6 WPF application, it's only the .NET 6 iOS build that has this issue so far. I've yet to try it on Android or MacOS. |
|
cc @radical @steveisok since this may be iOS specific and therefore not a WCF issue - perhaps they have seen something similar. |
|
Given the lack of any Xamarin iOS types in the stack is the reason I bounced it over to the runtime at first. |
|
I just checked, and this works fine on macOS Desktop with NET6. |
|
This appears to be the location of the exception. |
|
@simonrozsival Please give this a look and see if you can find anything. |
|
I managed to reproduce the issue locally. When the exception that @chamons pointed out is throw, the state is:
The raw HTTP response is: HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/10.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
X-Powered-By-Plesk: PleskWin
Date: Thu, 08 Sep 2022 07:57:57 GMT
Content-Length: 348
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><AddResponse xmlns="http://tempuri.org/"><AddResult>3</AddResult></AddResponse></soap:Body></soap:Envelope>As far as I can tell the actual size of the body is 325 bytes. I think the @chamons can you share the macOS desktop project so I can try to check why that behaves differently? |
|
@simonrozsival I've added a WPF .NET 6 application to my example that isn't throwing a ProtocolException if that's of any help. |
|
I've run Fiddler against the WPF build and in this instance it's returning Content-Length: 325 so assume it must be something in how it's making the request. Request headers: Response headers: |
|
@DuncWatts That's interesting. I ran the request a couple more times and I got three different Anyway, I found a workaround that might help. If you can, add this property to your iOS project: The I'm not sure if this is the desired behavior of EDIT: So I ran the example in a console app with the latest changes to the |
|
@karelz is the behavior of |
|
WCF has the ability to enable modifying the HttpMessageHandler stack. There's a blog post here that demonstrates how to modify the behavior of the HttpClientHandler where you can wrap it if needed. If you need to keep using the native implementation, you could wrap it with an implementation which removes the Content-Length header once the response has been received before returning the response message to WCF. This will cause WCF to switch to a mode where it keeps reading the content until it either reaches the end, or it hits the configured MaxReceivedMessageSize byte limit. |
|
@simonrozsival, @DuncWatts, @karelz, which repo is the best place to track this? I think it's been sufficiently investigated to know this is not an issue WCF's implementation or usage of HttpClient. |
|
If @karelz confirms this is a bug then we should move it to dotnet/runtime. |
|
@simonrozsival can you please restate what exactly is the If we find a bug in some component, I would recommend to create a new bug with specific details instead of this one which is IMO not super-clear at the moment. (there is of course always an option it is just me being slow ;)) |
|
@karelz when |
|
Yeah, that looks like a bug to me. |
|
Removing the Content-Length header using a DelegatingHandler works a charm thank you. The previous workaround of setting UseNativeHttpHandler to false did work but triggered a lot of errors with the linker which I was struggling to resolve. |
|
tl;dr: The root of the problem is gzip compression of the response. The server works correctly. It's not a bug in .NET. It's possibly a bug in WCF and/or @karelz I won't open any issue in dotnet/runtime after all. Sorry for the confusion 😄 I did some more digging and I realized that my previous conclusions were incorrect. I overlooked the fact that the response is gzipped and so the Content-Length contains the size of the compressed payload (interesting in this case the gzipped payload is 348 B instead of the original 325 B). WCF sets the The .NET implementation (``) makes the @mconnew The docs of the |
|
If decompression happened, or the server returned both the content length and chunked transfer encoding, or some handler somewhere changed the content/headers, this verification logic will be wrong.
|
|
Ah, I see you just commented that decompression was indeed the issue. |
|
What was the behavior with HttpWebRequest? We are using the exact same logic on .NET Framework. |
|
I am facing similar issue on Maui Android on .net 7 @chamons did you find any work around for this |
From @DuncWatts on Mon, 05 Sep 2022 12:20:03 GMT
I'm porting some code over from an existing Xamarin.Forms application however the WCF client I've written fails when run as a .NET 6.0 iOS application.
As WCF connected services don't work within iOS due to the restrictions on emitted code, I use a reference generated by the Silverlight tooling as a workaround and add System.ServiceModel.Http to use it.
Steps to Reproduce
I've found a random soap service to demonstrate this (http://www.dneonline.com/calculator.asmx?WSDL) and created a .NET Standard 2.0 class library that contains the WCF client and the code that calls it. I've then created a simple .NET 6.0 iOS application and a Xamarin.iOS application that executes that code that calls the webservice. In the Xamarin.iOS application it can correctly call the webservice while the .NET 6.0 iOS application fails with the stack trace below.
Expected Behavior
Web service is called correctly
Actual Behavior
Exception thrown when calling web service:
Environment
Version information
Build Logs
msbuild.zip
Example Project (If Possible)
WcfExample.zip
Copied from original issue xamarin/xamarin-macios#15866
The text was updated successfully, but these errors were encountered: