Re: [XHR] test nitpicks: MIME type / charset requirements

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 <annevk@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/
>