You made the whole thing a lot clearer to me, thank you :) It seems strange the spec would require a case-sensitive value for Content-Type in certain circumstances. Are these deviations from the case-insensitiveness of the header really necessary ? Are they beneficial for authors ? It seems to me they promote bad practice (case-sensitive testing of Content-Type).
On 7 May 2013 01:20, Anne van Kesteren <ann...@annevk.nl> wrote: > On Mon, May 6, 2013 at 3:44 PM, Julian Aubourg <j...@ubourg.net> wrote: > > I don't quite get why you're saying HTTP is irrelevant. > > For the requirements where the XMLHttpRequest says to put a certain > byte string as a value of a header, that's what the implementation has > to do, and nothing else. We could make the XMLHttpRequest talk about > the value in a more abstract manner rather than any particular > serialization and leave the serialization undefined, but it's not > clear we should do that. > > > > As an example, regarding the content-type request header, the XHR spec > > clearly states: > > > >> If a Content-Type header is in author request headers and its value is a > >> valid MIME type that has a charset parameter whose value is not a > >> case-insensitive match for encoding, and encoding is not null, set all > >> the charset parameters of that Content-Type header to encoding. > > Yeah, this part needs to be updated at some point to actually state > what should happen in terms of parsing and such, but for now it's > clear enough. > > > > So, testing for a response Content-Type case-sensitively is not correct. > > It is if the specification requires a specific byte string as value. > > > > Things are less clear to me when it comes to white spaces. I find HTTP > quite > > evasive on the matter. > > You can have a space there, but not per the requirements in XMLHttpRequest. > > > -- > http://annevankesteren.nl/ >
