|  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
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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: karel at linux dot be
New email:
PHP Version: OS:


 [2006-01-28 00:16 UTC] karel at linux dot be
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"


Add a Patch

Pull Requests

Add a Pull Request


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>
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]
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 (cli) (built: Apr 23 2009 14:35
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 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 (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]
I am pretty sure this is fixed by my patch from 9 months ago:

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

PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Fri Jan 28 23:03:34 2022 UTC