24845 2014-02-27 22:53:00 +0000 Merge <form> and URL error modes? 2014-04-11 10:54:23 +0000 1 1 1 Unclassified WHATWG Encoding unspecified PC All RESOLVED FIXED P2 normal Unsorted 1 ian annevk bzbarsky hsivonen mike www-international xn--mlform-iua zcorpan sideshowbarker+encodingspec oldest_to_newest 101551 0 ian 2014-02-27 22:53:00 +0000 http://encoding.spec.whatwg.org/#encodings # Otherwise, if encoder's error handling mode is URL, emit byte 0x3F. As far as I can tell, Chrome and Safari actually do the same for the URL mode as they do in the <form> mode. (I didn't check IE. Firefox goes back and reserialises the whole segment using UTF-8 instead.) e.g.: http://damowmow.com/playground/tests/urls/001.html 101615 1 zcorpan 2014-02-28 14:32:37 +0000 IE will send a literal ? whereas per spec the ? should be percent-encoded IIRC. 102703 2 annevk 2014-03-20 13:43:52 +0000 Henri, what do you think? How do you want to align Gecko? Making the error handling the same is certainly attractive. 103260 3 hsivonen 2014-04-02 07:47:53 +0000 (In reply to Anne from comment #2) > Henri, what do you think? How do you want to align Gecko? Making the error > handling the same is certainly attractive. I think I don't have enough familiarity with this issues to respond in an informed way. Moreover, I don't find the sentence that Hixie quoted in the spec to figure out the context of the question. I might be able to develop an opinion if I knew what case exactly we are talking about here. 103270 4 zcorpan 2014-04-02 10:01:18 +0000 There are two cases which currently are handled differently in the spec: Consider a document (with a http: base URL) with encoding windows-1251 which includes a link <a href="?å"> and a form <form><input name=x value="å"></form>. å is not representable in windows-1251. The former is turned into ?%3F and the latter is turned into ?%26%23229%3B. The proposal is to make both ?%26%23229%3B. The proposal matches WebKit/Blink. IE almost matches the current spec, it just doesn't percent-escape the "?". Gecko switches to utf-8 for the whole URL and gets ?%C3%A5. I think the <form> handling is interoperable already. I think the relevant part of the spec is http://encoding.spec.whatwg.org/#concept-encoding-process 103339 5 hsivonen 2014-04-03 13:02:25 +0000 (In reply to Simon Pieters from comment #4) > Consider a document (with a http: base URL) with encoding windows-1251 which > includes a link <a href="?å"> and a form <form><input name=x > value="å"></form>. å is not representable in windows-1251. The former > is turned into ?%3F and the latter is turned into ?%26%23229%3B. The > proposal is to make both ?%26%23229%3B. > > The proposal matches WebKit/Blink. > > IE almost matches the current spec, it just doesn't percent-escape the "?". I could live with matching WebKit/Blink. The probability of IE's approach ever leading to a useful URL seems low. > Gecko switches to utf-8 for the whole URL and gets ?%C3%A5. Hmm. Switching the encoding when one non-representable character is added doesn't seem like a good idea to me, especially if other browsers don't do the same. CCing bz in the hope of getting background info. 103358 6 bzbarsky 2014-04-03 14:46:28 +0000 I don't recall exactly what necko does in this situation and why... Worth checking with one of the current necko peers. 103392 7 xn--mlform-iua 2014-04-04 05:16:33 +0000 (In reply to Henri Sivonen from comment #5) > (In reply to Simon Pieters from comment #4) > > Gecko switches to utf-8 for the whole URL and gets ?%C3%A5. > > Hmm. Switching the encoding when one non-representable character is added > doesn't seem like a good idea to me, especially if other browsers don't do > the same. CCing bz in the hope of getting background info. Well, compared with what they do for erroneous URLs with *representable* characters, then both Firefox and Webki/Blink switch the encoding when one non-representable character is added. They just do it different ways. Firefox just follows the normal procedure of representing code points higher than U+009F as UTF-8 percent-encoded characters. Webkit/BLink do the same - but only for the *representable* characters. The issue here is, I guess, 'storing': The percent-encoding is decoded e.g. when storing a form. And so, in Webkit/Blink, ?%26%23229%3B becomes ?å, which is compatible even with Cyrillic encodings. For IE, the character is stored as representable, and therefore wrong, character. For Firefox, unless it performs some extra encoding step after the decoding, the percent-encoded character is probably stored as UTF-8 encoded characters read through a non-UTF parser For storing a form, the Webkit/Blink behavior seems more fruitful. Inside a Web page, the Firefox method might be better? 103667 8 annevk 2014-04-10 11:36:12 +0000 I asked Necko guys before (just checked again on #necko, no response so far) and I believe nobody in charge at the moment really knows much or cares for the URL parsing code. 103732 9 annevk 2014-04-11 10:54:23 +0000 https://github.com/whatwg/encoding/commit/73874f405d64a061eee35f4211cb3fe1e903a934