This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In section 4.7.1., step 2 states "let method be the result of deflating method". This statement is not well defined since method is a DOMString (a 16-bit coding unit sequence) and the results of deflating method is an 8-bit (byte) sequence. Furthermore, step 3 states "if method is a case-insensitive match for CONNECT, DELETE, GET, HEAD, OPTIONS, POST, PUT, TRACE, or TRACK subtract 0x20 from each byte...". Here, "method" is obviously being interpreted as a byte sequence (a deflated DOMString) but in contravention of its declared type (DOMString). Moreover, the rule talks about a "case-insensitive match for CONNECT, ...", but these strings "CONNECT", etc., are presumably interpreted as DOMStrings, since that is the only string type being used. The same problem occurs under 4.7.2 steps 2, 3, and 4.
It uses case-insensitive on bytes in the same manner that HTTP uses case-insensitive on bytes. I'm not really sure there's a problem here.
(In reply to comment #1) > It uses case-insensitive on bytes in the same manner that HTTP uses > case-insensitive on bytes. I'm not really sure there's a problem here. the problem is that: (1) method is defined as a DOMString (2) step 2 states let method = deflated(method) (3) but deflated(method) is a 8-bit byte sequence per section 3, not a DOMString then also: (4) step 3 says perform case-insensitive-match(deflated(method),"CONNECT") (5) but "CONNECT" is a DOMString as such, the prose is consistently *mixing* operations on two different data types
What makes you think "CONNECT" is a DOMString in that sentence?
(In reply to comment #3) > What makes you think "CONNECT" is a DOMString in that sentence? because all string literals in JS are effectively DOMString, and because method is defined as DOMString, and because nothing in the text says ascii("CONNECT") or latin1("CONNECT")
Anyway, HTTP should not be a model to the follow I guess; it's quite terrible. Suggestions for how to phrase it instead?
There is nothing that says that is a JavaScript string literal though.
(In reply to comment #5) > Anyway, HTTP should not be a model to the follow I guess; it's quite terrible. > Suggestions for how to phrase it instead? agreed; yes I can suggest a rephrase, but if you permit me some time, i'll provide something over the weekend after i finish my review; i may have similar comments for other text, so it would be easier to deal with them all in one go...
(In reply to comment #6) > There is nothing that says that is a JavaScript string literal though. let's just agree that the text is ambiguous since it is using a combination both 16-bit (UTF-16) and 8-bit (LATIN1) variables and operations; so in this context, it needs to be clear regarding the use of bare tokens in the text; i will make a proposal to address and then we can word smith to obtain mutual satisfaction (i hope)
Thanks to the new IDL ByteString concept this is now resolved. http://dvcs.w3.org/hg/xhr/rev/bc6759d87d74