Mark, you've made my day. Many thanks!
Regards, Andrey. On 05.07.2017 22:19, mozilla-lists.mbou...@spamgourmet.com wrote: > RFC 2368 and RFC 1738 are obsoleted by newer versions. I haven't read > through all of them in detail, but for what it's worth RFC 6068 (which > replaces RFC 2368) mentions in section 5: > Current implementations encode > a space as '+', but this creates problems because such a '+' standing > for a space cannot be distinguished from a real '+' in a 'mailto' > URI. When producing 'mailto' URIs, all spaces SHOULD be encoded as > %20, and '+' characters MAY be encoded as %2B. > So that at least acknowledges that expected handling of a '+' is > ambiguous, and that anyone producing mailto URIs should encode spaces as > %20. A quick search of the others didn't turn up any obvious mention of > encoding spaces as '+'. Were there specific sections where you saw this > mentioned? > > "application/x-www-form-urlencoded" is a content type used in HTTP POST > requests, in which the content is in a similar format to URL query > strings. I'm not sure off the top of my head whether the query part of a > URI is defined to be exactly the same format as > "application/x-www-form-urlencoded" content, nor whether the current > version allows encoding spaces as '+'. > > All in all, if you want consistent behaviour, it's probably best to use > %20 to represent a space even if some applications also accept '+'.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
