Subject: [HASMAT] Parsing Content-Type

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 13 Jul 2010 12:21:09 +0200

I was wondering if http://tools.ietf.org/html/draft-abarth-mime-sniff  
should not contain the error handling rules for parsing the Content-Type  
as well. It seems potentially dangerous if one user agent were to treat  
the value "text/html;" as bogus and fallback to "text/plain" whereas  
another would treat it as "text/html".

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Jul 2010 13:04:17 +0200

> another would treat it as "text/html".

If the *intent* was to send "text/html" then the only problem I see is 
that some recipients would see plain text.

Speaking of which: why would the fallback be "text/plain"?

If the intent was different, why send the header in the first place?

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Tue, 13 Jul 2010 09:10:56 -0700

>> another would treat it as "text/html".

The draft used to contain the parsing rules for extracting the
charset, etc.  My guess is that this draft will be controversial
enough as is.

> If the *intent* was to send "text/html" then the only problem I see is that
> some recipients would see plain text.

Indeed.  That sort of mis-match is likely to be a bad user experience
if it occurs.

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

> If the intent was different, why send the header in the first place?

That's a question for the server operator.  I can look up this
particular sequence of bytes, but server do end up sending a bunch of
crazy things for whatever reason.  The UA is then faced with the
question of how to interpret the response.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Jul 2010 18:26:13 +0200

On 13.07.2010 18:10, Adam Barth wrote:
> ...

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

2) Treated as invalid header value, thus same as absent content-type header.

In case 2 I wouldn't expect a default text handling.

> ...

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Tue, 13 Jul 2010 09:40:13 -0700

> 1) Treated as missing parameter, thus as "tex/html", or

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

> 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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Jul 2010 18:53:12 +0200

On 13.07.2010 18:40, Adam Barth wrote:
> On Tue, Jul 13, 2010 at 9:26 AM, Julian Reschke<[email-masked]>  wrote:

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

> $ nc -l 9191<  testcase
> Loading<http://localhost:9191/dd>  in Firefox, Chrome, Safari, and

Same for IE8.

> result of the Content-Type header parser.

Indeed.

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

> internally to generate the observable behavior.

Indeed.

Best regards, Julian