12819 2011-05-30 13:07:40 +0000 Fully define application/x-www-form-urlencoded 2011-08-15 03:46:14 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#url-encoded-form-data P3 normal --- 1 contributor ian annevk geoffers+w3cbugs ian julian.reschke mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 48924 0 contributor 2011-05-30 13:07:40 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/ Section: http://www.whatwg.org/specs/web-apps/current-work/#url-encoded-form-data Comment: How do you decode this format on the server? There seems to be no definition of the format, apart from the definition of how to encode it. Expecting every implementer to reverse this algorithm seems prone to mistakes. Posted from: 109.246.246.173 User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Ubuntu/10.10 Chromium/13.0.772.0 Chrome/13.0.772.0 Safari/535.1 53073 1 mike 2011-08-04 05:06:23 +0000 mass-moved component to LC1 54799 2 ian 2011-08-12 20:49:08 +0000 Wow, looks like nobody's ever registered application/x-www-form-urlencoded, HTML4 doesn't define how to parse it, and there's no other documentation worth anything on it either. Ok I guess we should register the type in the IANA considerations section, and then in 4.10.22.5 URL-encoded form data add a paragraph and list at the end saying how to decode it. Should probably mention _charset_ there too. While I'm at it maybe also add a similar section for multipart/form-data (saying to see the RFC), and for text/plain (saying it's ambiguous and can't be parsed). So the parsing rules here should be: - cut on &s => list of name-value pairs - cut name-value pairs on =s limit 1 => names, values - replace +s in names, values with 0x20 - expand %xxs to corresponding bytes - look for _charset_ name, treat value as encoding if found. otherwise use the encoding determined by magic - decode names, values per that encoding Might want to mention the isindex exception? Maybe not. 54801 3 geoffers+w3cbugs 2011-08-12 20:57:33 +0000 Probably should document the isindex exception. What happens about non-ASCII bytes in the form submission? 54802 4 ian 2011-08-12 21:10:29 +0000 isindex exception is just that if you're expecting isindex input, you skip the two "cut" steps and just process one "value" being the whole input. Not sure how I'll phrase that exactly. 54976 5 annevk 2011-08-14 11:09:51 +0000 Not really useful as far as I can tell, but for reference: http://lists.w3.org/Archives/Public/www-archive/2006Sep/thread.html#msg30 http://tools.ietf.org/html/draft-hoehrmann-urlencoded (last updated September 2010) 55010 6 ian 2011-08-15 03:45:27 +0000 Yeah there doesn't seem to be any implementor interest around that format, so probably best to ignore it. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments. 55011 7 contributor 2011-08-15 03:46:14 +0000 Checked in as WHATWG revision r6450. Check-in comment: Define how to parse the various form submission formats. Register the legacy one. Some editorial tweaks for consistency. http://html5.org/tools/web-apps-tracker?from=6449&to=6450