Re: [HASMAT] Parsing Content-Type

[Julian Reschke <[e-mail]>]

On 13.07.2010 18:40, Adam Barth wrote:
> 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.

It's a typo; I meant to say "text/html".

>> 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

Same for IE8.

> know that this is not a result of the sniffing algorithm but rather a
> result of the Content-Type header parser.

Indeed.

So what appears to happen is what I tried and failed to explain as 
option 1).

> 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.

Indeed.

Best regards, Julian