Doc #53187 [Fbk->Asn]: urlencode and ~ encodes differently in the various versions of the functions
| From: | asphp at dsgml dot com | Date: | Sun, 07 Nov 2010 05:52:36 +0000 |
| Subject: | Doc #53187 [Fbk->Asn]: urlencode and ~ encodes differently in the various versions of the functions | ||
| References: | 1 | Groups: | php.doc.bugs |
| Request: | Send a blank email to doc-bugs+get-5489@lists.php.net to get a copy of this message | ||
Edit report at http://bugs.php.net/bug.php?id=53187&edit=1
ID: 53187
User updated by: asphp at dsgml dot com
Reported by: asphp at dsgml dot com
Summary: urlencode and ~ encodes differently in the various
versions of the functions
-Status: Feedback
+Status: Assigned
Type: Documentation Problem
Package: Documentation problem
PHP Version: trunk-SVN-2010-10-27 (SVN)
Assigned To: frozenfire
Block user comment: N
New Comment:
In the function: php_raw_url_encode
Change:
if (!isalnum(str[y]) && strchr("_-.", str[y]) != NULL) {
to:
if (!isalnum(str[y]) && strchr("_-.~", str[y]) != NULL) {
(Around line 588, add the ~ to the EBCDIC version of the function.)
Previous Comments:
------------------------------------------------------------------------
[2010-11-07 02:31:54] frozenfire@php.net
Could you please provide more information regarding the discrepancy in
the EBCDIC version? I'm not familiar with EBCDIC.
------------------------------------------------------------------------
[2010-11-07 02:10:47] asphp at dsgml dot com
Thanks for fixing this!
I think you should also fix the inconsistency between the ASCII and
EBCDIC versions before closing this. (I know EBCDIC doesn't work right,
but the bug should be fixed for whenever it does work.)
Should I reopen it?
------------------------------------------------------------------------
[2010-11-06 20:16:13] frozenfire@php.net
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.
Thank you for the report, and for helping us make our documentation
better.
------------------------------------------------------------------------
[2010-11-06 20:12:49] frozenfire@php.net
Automatic comment from SVN on behalf of frozenfire
Revision: http://svn.php.net/viewvc/?view=revision&revision=305134
Log: Updated to reflect RFC 3986, as per bug #53187.
------------------------------------------------------------------------
[2010-10-28 17:16:37] cataphract@php.net
RFC 3986, which apparently rawurlencode is to follow (though the
documentation mentions the obsolete 1738 -- that should be changed):
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
For consistency, percent-encoded octets in the ranges of ALPHA
(%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E),
underscore (%5F), or tilde (%7E) should not be created by URI
producers and, when found in a URI, should be decoded to their
corresponding unreserved characters by URI normalizers.
So the behavior of rawurlencode is correct in not escaping ~.
urlencode, on the other hand, mentions the encoding mechanism
application/x-www-form-urlencoded. This is defined in the HTML 4.01 spec
and Xforms 1.1 spec:
* http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1
* http://www.w3.org/TR/2009/REC-xforms-20091020/#serialize-urlencode
The first points to RFC 1738, under which ~ should be encoded, as it is.
The second mentions reserved characters "as defined by [RFC 2396] as
amended by subsequent documents in the IETF track", so it would refer to
the RFC 3986, which obsoletes 2396. I'd say the current behavior is
correct because it "plays safe" by following the HTML 4/RFC 1738.
As for EBCDIC, well, the support is broken anyway.
urlencode/rawurlencode should receive the string in UTF-8 encoding,
since that's the only way it can give meaningful results. The current
implementation assumes that, in an EBCDIC system, it receives the string
in EBCDIC. But yes, there's an inconsistency between the ASCII and
EBCDIC version.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=53187
--
Edit this bug report at http://bugs.php.net/bug.php?id=53187&edit=1