16292 2012-03-09 21:59:34 +0000 conflation of DOMString and deflated DOMString 2012-06-25 07:55:21 +0000 1 1 1 Unclassified WebAppsWG XHR unspecified All All RESOLVED FIXED http://dvcs.w3.org/hg/xhr/raw-file/8d4e9ccfdbd4/Overview.html P2 normal --- 1 glenn annevk mike public-webapps public-webapps-bugzilla oldest_to_newest 65239 0 glenn 2012-03-09 21:59:34 +0000 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. 65241 1 annevk 2012-03-09 22:04:44 +0000 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. 65244 2 glenn 2012-03-09 22:21:55 +0000 (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 65247 3 annevk 2012-03-09 22:24:32 +0000 What makes you think "CONNECT" is a DOMString in that sentence? 65248 4 glenn 2012-03-09 22:27:20 +0000 (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") 65249 5 annevk 2012-03-09 22:27:53 +0000 Anyway, HTTP should not be a model to the follow I guess; it's quite terrible. Suggestions for how to phrase it instead? 65250 6 annevk 2012-03-09 22:28:15 +0000 There is nothing that says that is a JavaScript string literal though. 65251 7 glenn 2012-03-09 22:30:57 +0000 (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... 65252 8 glenn 2012-03-09 22:33:38 +0000 (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) 69379 9 annevk 2012-06-25 07:55:21 +0000 Thanks to the new IDL ByteString concept this is now resolved. http://dvcs.w3.org/hg/xhr/rev/bc6759d87d74