ID: 39078
Comment by: boriss at web dot de
Reported By: main at springtimesoftware dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows XP
PHP Version: 5.1.6
New Comment:
I'd like to see an option to change runtime behavior of PHP, too. Even
if the Javascript function escape() would work a user could still enter
an URL with a query string himself. Imagine you have a search engine and
someone enters an URL with ?query=C++. If you use $_GET['query'] you
just don't know if someone searches for "C++" or "C ".
Previous Comments:
------------------------------------------------------------------------
[2008-07-16 20:18:49] edA-qa at disemia dot com
I would also like to add that decoding '+' to a space is just plain
wrong. I got burnt again by this when using base64_encode, which should
produce URL safe strings, but for PHP it doesn't, since it may include
the '+'.
A global option to use the proper rawurldecode would be great.
Otherwise I'm stuck, like many developers, in reparsing the query
string/url manually and unable to use _POST and _GET.
------------------------------------------------------------------------
[2008-06-12 00:25:52] jerm at live dot com
I'm with David on this.
On the client-side, I'm using the JavaScript escape() function to
encode data for sending to the server using a POST ajax request.
(Original bug report refers to $_GET, but this is also affecting
$_POST)
The server sees both plus signs "+" and "%20" as spaces. And yes, PHP
is seeing the plus, untouched by Apache, as I can prove using:
echo file_get_contents("php://input"); // Display raw POST
This is very frustrating. I'm currently getting around this by parsing
the raw POST data manually (above), and not using the pre-parsed $_POST
data.
------------------------------------------------------------------------
[2006-10-10 13:30:10] main at springtimesoftware dot com
So, that's it? Just a few ignorant attempts to classify this feature
request as Bogus, with no assignment to a developer to make this feature
request happen?
I'm disappointed.
An option to process incoming URL args using rawurldecode instead of
urldecode would benefit so many users!
David Spector
------------------------------------------------------------------------
[2006-10-07 22:53:52] main at springtimesoftware dot com
I'm not sure I'm following you.
Section "Reserved:" in RFC 1738 (at
http://www.freesoft.org/CIE/RFC/1738/4.htm) states:
----
Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters used for their reserved purposes may be used
unencoded within a URL.
----
Since "+" is listed, I would expect that any agent that obeyed this RFC
would transmit "+" unchanged.
That means that Apache should transmit "+" unchanged to PHP.
This is why I would be surprised to find that Apache is the cause of
this problem.
Indeed, if I browse (using IE 6.0) to a Web page that contains a call
to phpinfo(), browsing using a URL that contains the argument
"Arg=+%20", then phpinfo() reports that _SERVER["QUERY_STRING"] has the
value "Arg=+%20". (I just did this, I'm not making this up.)
This confirms that the plus sign is getting to PHP okay.
So wouldn't you agree with me that Apache cannot be causing this
problem?
PHP must be using urldecode() when it parses the arguments into the
$_GET array, yes? Otherwise, how would the plus sign in the argument
become a space?
David
------------------------------------------------------------------------
[2006-10-07 22:15:37] der...@php.net
It's not hard to believe... it's what the RFC states:
http://www.freesoft.org/CIE/RFC/1738/4.htm, read the section "unsafe".
------------------------------------------------------------------------
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/39078
--
Edit this bug report at http://bugs.php.net/?id=39078&edit=1
