You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I'm interpreting RFC 2616 Section 7.2.1 [1] correctly, the following excerpt implies that this header is not required, and only recommended for responses containing a non-empty body:
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If
and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its
content and/or the name extension(s) of the URI used to identify the
resource. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".
This appears to be a bug that could be fixed with a simple null check, but am wondering if this has already been encountered/considered and there is a configuration option we may be overlooking. At the moment we're working around this by setting the header if empty to "text/plain" in HttpApplication.PostRequestHandlerExecute.
If the Content-Type header is not set in the response, we receive an ArgumentNullException at https://github.com/turquoiseowl/i18n/blob/master/src/i18n/LocalizedApplication.cs#L336
If I'm interpreting RFC 2616 Section 7.2.1 [1] correctly, the following excerpt implies that this header is not required, and only recommended for responses containing a non-empty body:
This appears to be a bug that could be fixed with a simple null check, but am wondering if this has already been encountered/considered and there is a configuration option we may be overlooking. At the moment we're working around this by setting the header if empty to "text/plain" in HttpApplication.PostRequestHandlerExecute.
1 - https://tools.ietf.org/html/rfc2616#section-7.2.1
The text was updated successfully, but these errors were encountered: