Path: csiph.com!usenet.pasdenom.info!news.albasani.net!news2.arglkargh.de!diablo1.news.osn.de!news.osn.de!diablo2.news.osn.de!217.188.199.168.MISMATCH!takemy.news.telefonica.de!telefonica.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <2094311.UPhlsrQmMF@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Sat, 25 Aug 2012 15:20:44 +0200 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 7Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <4919648.gLsDIqzOUs@PointedEars.de> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 49 NNTP-Posting-Date: 25 Aug 2012 15:20:45 CEST NNTP-Posting-Host: 0c999e4f.newsspool2.arcor-online.net X-Trace: DXC=Ek^;\hfg1GDC4i^e1BZ=_HA9EHlD;3YcB4Fo<]lROoRA8kFVH X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript:15556 Christoph Becker wrote: > Thomas 'PointedEars' Lahn wrote: >> Christoph Becker wrote: >>> For POST requests escaping on the client side should not be necessary. >> Incorrect. The payload of the POST request (the message body) needs to >> be URI-percent-encoded, see RFC 2616. > > Thanks for correcting me. I was not aware of this, as in the past I > always used jQuery to send Ajax POST requests, and the respective jQuery > methods obscure this fact by doing the encoding behind the scenes, > what's AFAIK not documented. To be precise (I have had time to re-read the RFC), URI-percent-encoding is not mandatory. But if the payload contains ASCII characters, a form of encoding that results in ASCII octets is. Per section 4.3, RFC 2616 (HTTP/1.1) mandates that the message body must contain only ASCII octets. This is easily accomplished in a symmetrical way with percent-encoding as defined in RFC 3986 ("Uniform Resource Identifiers"), section 2.1. (In ECMAScript implementations this is implemented as the encodeURIComponent() function.) The message body may also, instead, be encoded using the specified Transfer- Encoding, the default of which is `identity' (no special encoding; see section 14.41). Other Transfer-Encodings specified there already include the common `gzip', but AIUI as long as both client and server support it, any transfer encoding that results in an ASCII-only message body may be used. It is possible that a browser API would apply a suitable encoding before transmitting the HTTP request message if it encountered non-ASCII characters in the payload. However, that is nothing that should be relied upon. The possibility of sending the payload gzipped instead of percent-encoded if the server supports it certainly should be investigated further. This would make sense if the amount of client-side script code required for gzipping were less than the amount of data saved in the payload when switching from percent-encoding to gzipping. On the other hand, it might be a good idea if browser APIs would use gzip transparently if supported by the server and deemed reasonable; previous gzipping by scripts would be of double disadvantage then. Ceterum censeo jQuery esse delendam. PointedEars -- When all you know is jQuery, every problem looks $(olvable).