Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SoapCore uses chunked transfer-encoding on netstandard2.0 version #1015

Closed
vidrenning opened this issue Feb 9, 2024 · 0 comments · Fixed by #1016
Closed

SoapCore uses chunked transfer-encoding on netstandard2.0 version #1015

vidrenning opened this issue Feb 9, 2024 · 0 comments · Fixed by #1016

Comments

@vidrenning
Copy link
Contributor

When using SoapCore with .NET Framework and ASP.NET Core 2.1, chunked transfer encoding is used. I have run into some compatibility issues with some existing applications, so I think chunked transfer-encoding should not be used. This has already been implemented in #843 for ASP.NET Core >= 3.0, but on ASP.NET Core 2.1, chunked transfer-encoding is still used.

vidrenning added a commit to vidrenning/SoapCore that referenced this issue Feb 9, 2024
Setting the Content-Length header explicitly will disable chunked
transfer-encoding. However this was only done for one of the two
WriteMessageAsync methods in SoapMessageEncoder. I have changed the
other method to also set the Content-Length header.

To do this I have used a MemoryStream. The other implementation used
a StringWriter, which is not ideal, because it will convert to and from
different encodings. We only want to find out the length of the stream,
so a MemoryStream is faster and sufficient. Also changed the other
WriteMessageAsync implementation to use a MemoryStream and removed the
CustomStringWriter class.

Fixes DigDes#1015
vidrenning added a commit to vidrenning/SoapCore that referenced this issue Feb 9, 2024
Setting the Content-Length header explicitly will disable chunked
transfer-encoding. However this was only done for one of the two
WriteMessageAsync methods in SoapMessageEncoder. I have changed the
other method to also set the Content-Length header.

To do this I have used a MemoryStream. The other implementation used
a StringWriter, which is not ideal, because it will convert to and from
different encodings. We only want to find out the length of the stream,
so a MemoryStream is faster and sufficient. Also changed the other
WriteMessageAsync implementation to use a MemoryStream and removed the
CustomStringWriter class.

Fixes DigDes#1015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant