Re: [whatwg/xhr] Define Content-Type manipulation in terms of MIME Sniffing (#176)

domenic commented on this pull request.

Looks pretty good although as noted I really think we should add "get" to headers list, preferably before merging this or at least very soon after.

I still find this algorithm a bit confusing to try to follow by hand but I'll noodle on whether we can do anything better in a follow-up.

For tests it'd be worth testing everything in the MIME types JSON file, I think, to make sure that we're using the same parser here as everywhere else on the platform.

> -  match for `<code>Content-Type</code>` in <a>author request headers</a> has a
-  <a for=header>value</a> that is a <a>valid MIME type</a>, which has a `<code>charset</code>`
-  parameter whose value is not a <a>byte-case-insensitive</a> match for <var>encoding</var>, and
-  <var>encoding</var> is not null, then set all the `<code>charset</code>` parameters whose value is
-  not a <a>byte-case-insensitive</a> match for <var>encoding</var> of that <a>header</a>'s
-  <a for=header>value</a> to <var>encoding</var>.
-  <!-- XXX could still be better with parameter cross-ref -->
-
-  <!-- reminder: if we ever change this to always include charset it has
-  to be included as the first parameter for compatibility reasons -->
+  <p>Otherwise, if <var>encoding</var> is non-null, run these steps:
+
+  <ol>
+   <li><p>Let <var>value</var> be the <a for=header>value</a> of the <a>header</a> whose
+   <a for=header>name</a> is a <a>byte-case-insensitive</a> match for `<code>Content-Type</code>` in
+   <a>author request headers</a>.

I'd like to still get this fixed because it contrasts with "contains" very strongly. Reading without clicking links might lead one to say that this operation is byte-case-insensitive but the above check is case-sensitive.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/xhr/pull/176#pullrequestreview-110937018