search

turquoiseowl / i18n

Smart internationalization for ASP.NET
Other
556 stars 156 forks source link

Handling of null Content-Type #337

Closed jmpease closed 3 years ago

jmpease commented 7 years ago

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:

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.

1 - https://tools.ietf.org/html/rfc2616#section-7.2.1

turquoiseowl commented 7 years ago

Looks like a bug and there should be a null check. Happy to merge a fix - bit tied up at the moment.

vhatuncev commented 3 years ago

@turquoiseowl this can be closed