-
Notifications
You must be signed in to change notification settings - Fork 379
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
Set "default" 'Content-Type' header if none is provided #1032
Comments
Yes, that should be a TryParse. With that said it can be necessary to add a custom middleware to set Content-Type anyways. I solved that with a regular asp.net middleware (affects performance, but in my case it's much more important to stay backwards compatible than to maximize performance.
|
Should be fixed in #1033 |
Ha, the use case I have is not a standard SoapCore use case, so I did the "dumb" workaround by simply using Appreciate the rapid change! |
Problem
SoapCore currently throws an exception if no
Content-Type
header is provided. This can happen because v1.1.0.45 of this line inv1.1.0.45/src/SoapCore/MessageEncoder/SoapMessageEncoderDefaults.cs within the
ContentTypeToEncoding
method:Previous Behavior
In v1.0.0 this did not happen because the encodings were acquired using a different method that did not use the
System.Net.Http.Headers
namespace and theMediaTypeHeaderValue
parserv1.0.0/src/SoapCore/MessageEncoder/SoapMessageEncoderDefaults.cs
Easy Way Out
It's easy to say "make sure incoming requests have a content type, but for legacy systems this isn't always possible. If you run an external SOAP service, you may get requests that don't send this header. In order to preserve the existing behavior that 1.0.0 had (yes, some systems haven't upgraded!)
Proposed Solution
Thus, I propose
Content-Type
header to ensure a value can be parsedMediaTypeHeaderValue.TryParse(...)
instead of the regular Parse and add logic accordinglynull
is provided isn't ideal behaviorThe text was updated successfully, but these errors were encountered: