Re: [HASMAT] Parsing Content-Type

[Adam Barth <[e-mail]>]

On Tue, Jul 13, 2010 at 9:26 AM, Julian Reschke <[e-mail]> wrote:
> On 13.07.2010 18:10, Adam Barth wrote:
>>> Speaking of which: why would the fallback be "text/plain"?
>>
>> It depends on how the UA treats text/potato.  It would not be
>> unreasonable to treat text/potato similarly to text/plain, depending
>> on the UA's purpose.
>
> Hm, no. Imho.
>
> "text/html;" is a parse error according to the ABNF.
>
> So the likely outcomes seem to be:
>
> 1) Treated as missing parameter, thus as "tex/html", or

I don't understand where "tex/html" comes from in this discussion.

> 2) Treated as invalid header value, thus same as absent content-type header.
>
> In case 2 I wouldn't expect a default text handling.

Testing makes perfect:

$ cat testcase
HTTP/1.0 200 OK
Date: Tue, 13 Jul 2010 16:28:45 GMT
Expires: -1
Content-Type: text/html;

Potato
<b>Grass</b>
$ nc -l 9191 < testcase

Loading <http://localhost:9191/dd> in Firefox, Chrome, Safari, and
Opera causes the text "Grass" to be rendered bold, which means the
response is being treated as HTML.  Based on other information, we
know that this is not a result of the sniffing algorithm but rather a
result of the Content-Type header parser.

It's a separate question of whether we should specify this behavior in
this document, in another document, or not at all.  It's also a
separate question of what we would like to imagine is going on
internally to generate the observable behavior.

Adam