W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: [CORS] Charset in content type

From: Alexey Proskuryakov <ap@webkit.org>
Date: Mon, 16 Mar 2009 14:29:34 +0300
Cc: public-webapps <public-webapps@w3.org>
Message-Id: <CA60BB38-7867-46BF-95F4-22FFE8556F4D@webkit.org>
To: Anne van Kesteren <annevk@opera.com>

16.03.2009, Χ 14:12, Anne van Kesteren ΞΑΠΙΣΑΜ(Α):

>> An unrelated question about the same sentence is why the header  
>> field value is matched case insensitively. My understanding is that  
>> this rule was meant to prevent exposing unsuspecting servers to  
>> requests that couldn't be made with existing mechanisms such as  
>> form submission, and I'd be quite surprised if any major browser  
>> used anything but lower case here.
> Media types are ASCII case-insensitive. E.g. if someone does
>  setRequestHeader("Content-type", "TEXT/Plain")
> that should just work.

The difference is that when one does <form enctype="TEXT/Plain">, the  
MIME type on the wire is "text/plain", but with setRequestHeader, it's  
"TEXT/Plain". So, server-side code that does case-sensitive  
comparisons (something like if (contentType == "text/plain") ... else  
if (contentType == "multipart/form-data") else <assume application/x- 
www-form-urlencoded>) can be fooled. I'm not saying that this is a  
particularly likely a bug for servers to have, but it's also extremely  
easy to protect from in CORS.

- WBR, Alexey Proskuryakov
Received on Monday, 16 March 2009 11:30:09 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:14 UTC