Re: XHR: restrictions on request headers

On Apr 11, 2006, at 2:00 AM, Robin Berjon wrote:

> On Apr 11, 2006, at 02:03, Maciej Stachowiak wrote:
>> 2) It would allow a client to cause the UA to violate the http RFC  
>> (besides just requirements on syntax, obviously those are possible  
>> with any header).
>
> Do we really want to enforce this? I'm not entirely convinced that  
> it's our place to do so, and and I don't think that we want to  
> require that the UA validate all requests as it would be quite a  
> burden.

I don't think we should enforce all rules required by the HTTP RFC.  
As it happens, most request headers have no special requirements for  
the client besides the syntax, and I don't think we need to syntax- 
check the headers.

But in my opinion we should indeed restrict headers that have more  
specific semantic MUST-level requirements from being set at all. For  
example, the spec requires that the Date header must be the actual  
time of the request from an actual clock, or not sent at all. There  
doesn't seem to be a reason to let web content override this.

As it happens, the only headers I proposed for restriction solely  
under this category are "Date" and "Transfer-Encoding", and besides  
the protocol issue there doesn't seem to be any valid reason for web  
content to set them.

> That's not something that any of the HTTP libs I've used so far do.

NSURLConnection on Mac OS X won't let you override some of the  
headers if it would interfere with operation of the library itself or  
break stuff in general. For example, you can't set "Host" to be  
something other than the host in the URL being requested. You can't  
set "Conection" freely. Etc.

This is less restrictive than what I suggested, obviously, since this  
library is to be used by native code, not a nominally sandboxed  
scripting language, so the permitted level of tomfoolery is greater.

Regards,
Maciej

Received on Tuesday, 11 April 2006 16:03:27 UTC