Flurl: URI too long error

[dcworldwide]

When calling PostUrlEncodedAsync I'm receiving an error when the code tries to URL encode a large string (300kb).

      Invalid URI: The Uri string is too long.
System.UriFormatException: Invalid URI: The Uri string is too long.
   at System.UriHelper.EscapeString(String input, Int32 start, Int32 end, Char[] dest, Int32& destPos, Boolean isUriString, Char force1, Char force2, Char rsvd)
   at System.Uri.EscapeDataString(String stringToEscape)
   at Flurl.Url.EncodeQueryParamValue(Object value, Boolean encodeSpaceAsPlus) in C:\projects\flurl\src\Flurl.Shared\Url.cs:line 139
   at Flurl.Http.Configuration.DefaultUrlEncodedSerializer.Serialize(Object obj) in C:\projects\flurl\src\Flurl.Http.Shared\Configuration\DefaultUrlEncodedSerializer.cs:line 26
   at Flurl.Http.HttpExtensions.PostUrlEncodedAsync(IFlurlClient client, Object data, CancellationToken cancellationToken, HttpCompletionOption completionOption) in C:\projects\flurl\src\Flurl.Http.Shared\HttpExtensions.cs:line 513

The api we are calling is proprietary and does not accept POSTing application/json content. It only accepts a application/x-www-form-urlencoded payload.

[thiagolunardi]

This is a doubt, not a issue or improve request.

Will be better if you post your question at StackOverflow with FLURL tag.

You will have faster help, and it's the proper place to do it.

[dcworldwide]

I'm not doubtful. It's an issue as far as I can tell.

[thiagolunardi]

Can you fork and write a test reproducing the problem?

[tmenier]

Related to https://github.com/dotnet/corefx/issues/1936

[dcworldwide]

No need for a repro, https://github.com/dotnet/corefx/issues/1936 explains the issue perfectly well.

[tmenier]

I'd like to fix this by changing Url.EncodeQueryParamValue to use WebUtility.UrlEncode instead of Uri.EscapeDataString, but that's not supported on all targeted platforms unfortunately. Depending on major changes under consideration for #176, we might be able to do this after that is resolved but I'm not sure yet. (cc @kroniak )

[kroniak]

@tmenier Where WebUtilityUrlEncode is not supported? in PCL? We can wrap code in #if !PORTABLE

[tmenier]

@kroniak I believe that's what I saw, yes. I'd rather not have a PCL-only bug, but with the netstandard update very few platforms will get that version anymore, so that might be acceptable.

[tmenier]

@kroniak .NET 4.0 is where WebUtility.UrlEncode is missing. I tried wrapping the old implementation in #if NET40, but unfortunately .NET 4.5+ chooses net40 over netstandard, so I think the only way to fix this for all supported platforms is to add a net45 target to Flurl. Unless you know of another way? Thoughts?

[kroniak]

@tmenier No, I dont know another way to avoid it.

[GermanKuber-zz]

I am interested in work in this issue. You would give me more information. Did you discover one way to follow?

[tmenier]

This is back on my radar and I'll try to get it fixed for the next maintenance release. The best way to deal with this might be to just add a net45 specific target to Flurl so that .NET 4.5+ takes the "else" path here.

[tmenier]

Fixed (except in .NET 4.0) and released.

[tmenier]

This getting a re-do because as it turns out, WebUtility.UrlEncode is evil.

[tmenier]

An entirely different fix for this has been released. It would be great if someone could (re)test it against a very long string. https://www.nuget.org/packages/Flurl/2.6.0