php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #36183 urlencode wrongly decodes %00-chars
Submitted: 2006-01-28 00:16 UTC Modified: 2009-06-23 20:47 UTC
Votes:4
Avg. Score:3.2 ± 1.5
Reproduced:2 of 4 (50.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: karel at linux dot be Assigned:
Status: Closed Package: URL related
PHP Version: 4.4.0 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: karel at linux dot be
New email:
PHP Version: OS:

 

 [2006-01-28 00:16 UTC] karel at linux dot be
Description:
------------
PHP-version: 4.3.11 (linux), and 4.4.0 (windows)

I don't know if this bug is reproducible on any higher version of PHP as I don't have them to work on.


If you submit a POST/GET/parse_str() to a webpage, where a variable has an URLencoded string in it, which contains %00. It will end up being mangled totally.

Just check the reproduce-code, it'll be more clear then my explanation here.

Reproduce code:
---------------
  $comp_me = gzcompress('Compress me', 9);
  
  parse_str( 'var='. urlencode( $comp_me ) );
  
  var_dump( urlencode($var) );
  var_dump( urlencode( $comp_me ) );


Expected result:
----------------
I would expect to see 2 urlencoded strings, EXACTLY the same.

Actual result:
--------------
string(42) "x%DAs%CE%CF-%28J-.V%C8M%05%5C0%19%BD%04%3F"
string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F"
---------------------------------------^^^

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-01-28 06:02 UTC] judas dot iscariote at gmail dot com
not reproducible in latest PHP 5 CVS.
 [2006-02-06 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2006-03-23 01:52 UTC] judas dot iscariote at gmail dot com
Folks, this seems to be a real bug 64 bit related I think

since the OP test in x86 says me:

string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F"
string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F"

the expected result, Hoever in my linux amd64
I get

string(38) "x%DAs%CE%CF-%28J-.V%C8M%05%19%BD%04%3F"
string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F"

if this is not a bug,It have an unconsistent behaviuor...
 [2006-03-23 02:05 UTC] judas dot iscariote at gmail dot com
odd.. Im getting other different result with a 10 minutes ago   source code from the CVS  (in amd64)

string(42) "x%DAs%CE%CF-%28J-.V%C8M%05%5C0%19%BD%04%3F"
string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F"

the previuos result mentioned was from my system PHP compiled yesterday... :S
 [2006-03-23 02:09 UTC] judas dot iscariote at gmail dot com
Somebody needs to change the summary, and the PHP version, It can be reproduced with 5.1.3-dev CVS.
 [2009-06-23 17:15 UTC] me at evancarroll dot com
I've still got this problem. (this was not the subject of the below conversation)



11:51 < rasmus> main/php_variables.c has the php_default_treat_data() function which implements the actual default string 
                parsing logic in PHP.  And no, you can't change it.  It would break every PHP app ever written
...
11:52 < rasmus> the point is that it isn't broken
11:53 < rasmus> and if you think it is, then you are simply wrong.
11:53 < EvanCarroll> http://www.google.com/search?q=site%3Abugs.php.net+parse_str&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a
11:54 < rasmus> your point?
11:54 < rasmus> those are all people who don't understand how to use it
11:54 < rasmus> like I said, it is exactly the same code as PHP uses to parse incoming user data
11:55 < rasmus> and it adheres to all the same rules


Apparently, not reviewing the bug tracker is an indicator that everyone else doesn't know what they're doing.

32bit build
 [2009-06-23 18:07 UTC] rasmus@php.net
Works fine on 64-bit Linux with PHP 5.2.10
Also fine on 32-bit OSX with PHP 5.3.0

So, if you still see this problem, please be more specific about your PHP and OS versions.
 [2009-06-23 20:17 UTC] me at evancarroll dot com
ecarroll@x60s:~$ php --version
PHP 5.2.6-3ubuntu4.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 23 2009 14:35
:05) 
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
ecarroll@x60s:~$ md5sum /usr/bin/php5
5c83d3bd430c8673a9124c3adbb662f5  /usr/bin/php5

This is packaged php5 that Ubuntu ships with. It might be the Suhosin patch that is causing this problem.
 [2009-06-23 20:17 UTC] me at evancarroll dot com
(Ubuntu 9.04 Jaunty)
 [2009-06-23 20:37 UTC] phpbugcomment at pgregg dot com
Running the above code on my Ubuntu Jaunty 32bit does *not* exhibit the reported behaviour:

Linux puffy.pgregg.com 2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:48:10 UTC 2009 i686 GNU/Linux

PHP 5.2.8 with Suhosin-Patch 0.9.6.3 (cli) (built: Jun  7 2009 22:28:42)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
    with Suhosin v0.9.24, Copyright (c) 2007, by SektionEins GmbH

string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F"
string(41) "x%DAs%CE%CF-%28J-.V%C8M%05%00%19%BD%04%3F"
 [2009-06-23 20:47 UTC] rasmus@php.net
I am pretty sure this is fixed by my patch from 9 months ago:
http://cvs.php.net/viewvc.cgi/php-src/main/php_variables.c?r1=1.104.2.10.2.12&r2=1.104.2.10.2.13&pathrev=PHP_5_2

If someone can reproduce this in any PHP version after 5.2.6, let me know and I will re-open.


 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sat Dec 04 13:03:34 2021 UTC