Content-Type header parsing #39

This is related to #33, but subtly different. As explored in whatwg/mimesniff#30 browsers have different code paths for request and response Content-Type header parsing. Values such as */*, text/html in a response Content-Type header end up being interpreted as text/html, presumably for compatibility with deployed content.

This seems like another fallout of intermediaries adding potentially duplicate headers and (early) implementations being poorly tested for erroneous input.