[drupal-devel] [bug] Some URLs get ?PHPSESSID added to them

djnz drupal-devel at drupal.org
Tue Aug 9 16:41:00 UTC 2005

Issue status update for 
Post a follow up: 

 Project:      Drupal
 Version:      cvs
 Component:    base system
 Category:     bug reports
 Priority:     normal
 Assigned to:  Eric Scouten
 Reported by:  Eric Scouten
 Updated by:   djnz
 Status:       patch (code needs review)
 Attachment:   http://drupal.org/files/issues/both_sid_patches.patch (1.39 KB)

Yes, you are both right - I was being too kind to the code just FALSEing
it out, it should just be deleted. I don't want to lose the
url_rewriter.tags patch though so the attached patch has both.


Previous comments:

Thu, 13 Nov 2003 00:22:39 +0000 : Eric Scouten

Some URLs get ?PHPSESSID=(whatever) added to them. I find this
distracting and unnecessary for anonymous users. Submitting patch #147
for consideration to remove this issue.


Fri, 05 Dec 2003 14:39:25 +0000 : Kjartan

This is a local PHP configuration issue. Don't see it as something
Drupal should mess with, the less PHP settings Drupal messes with the


Fri, 05 Dec 2003 15:11:33 +0000 : killes at www.drop.org

Could you elaborate which config setting one has to tweak?


Fri, 05 Dec 2003 15:18:11 +0000 : Anonymous

php_flag session.use_trans_sid off
php_flag session.use_only_cookies on

The first will disable the automatic addition of the session ID to
internal URLs, the second will remove support for passing session IDs
in URLs. See http://php.net/session [1] for more info. BTW the above
settings are for Apache, in PHP.ini you should not add the php_flag
part, and you should use = inbetween the name and value...
[1] http://php.net/session


Mon, 07 Jun 2004 22:42:06 +0000 : shane

It seems that Drupal (via the .htaccess file) already "messes with" a
bunch of PHP settings.  For example, my Drupal install "came with"
these messed with settings:

   php_value register_globals        0
   php_value track_vars              1
   php_value short_open_tag          1
   php_value magic_quotes_gpc        0
   php_value magic_quotes_runtime    0
   php_value magic_quotes_sybase     0
   php_value arg_separator.output    "&"
   php_value session.cache_expire    200000
   php_value session.gc_maxlifetime  200000
   php_value session.cookie_lifetime 2000000
   php_value session.auto_start      0
   php_value session.save_handler    user
   php_value session.cache_limiter   none
   php_value allow_call_time_pass_reference  On
I'm not sure that adding two more "php_value" flags to the stock
.htaccess file is going to arguably mess with more than already is.  

Personally I find it extremely un-professional and very un-clean to
have funky PHPSESSID url strings tacked onto a majority of my URLs. 
I've worked extremely hard to implement clean URLs (above and beyond
the already great "clean url" feature of Drupal - I don't like them
being turned into muck.

I'd vote that these two flags be added to the .htaccess file that is
distributed with Drupal.  However, I'm uncertain of the overall true
impact of making these changes, so barring an technical reason - I
would absolutely request this as a feature.  I've implemented these in
many of my production sites already (just today) - we'll see what
impact they have.


Tue, 08 Jun 2004 02:56:00 +0000 : marky

It's a performance thing. You need to remember that while not everyone
has edit access to php.ini, those of us that do control our own servers
see no need for .htaccess directives that set php options.

>From the Apache docs [2]:

"Apache will look in every directory for .htaccess files. Thus,
permitting .htaccess files causes a performance hit, whether or not you
actually even use them! Also, the .htaccess file is loaded every time a
document is requested."

Ok, I'm lucky in that I control my own server, so I can effectively
remove the .htaccess file and move its config options to php.ini and
the vhost section of httpd.conf, thus speeding up the responsiveness of
my server.

But if you don't have that option there's nothing wrong with adding
those directives to your directory .htaccess file. That's what it's for
- it allows directory specific config options for those that don't have
access to their server config.

As Kjartan said, "the less PHP settings Drupal messes with the better".
I've got to agree - as far as I'm concerned it's already big enough. The
"php_value short_open_tag 1", "php_value session.auto_start 0" and
"php_value session.cache_limiter none" for example serve little
purpose, as they mirror the installation default settings (apart from
the last, where the available options are: nocache, private or public).

If you don't have the choice, use .htaccess, and add whatever
directives you see fit. But please remember that not everyone uses it.

Anyway, just my 2 beads.
[2] http://httpd.apache.org/docs-2.0/howto/htaccess.html#when


Tue, 08 Jun 2004 04:38:32 +0000 : cel4145

Why not add them, but commented out with an explanation? When I
encountered this problem, I had to spend a little time on drupal.org
finding the solution. However, I am familiar with the .htaccess file
from doing installs. If it had been included there commented out, I
would have probably remembered it.  After all, this is much the same
way that httpd.conf functions with it's many, optional, commented out
configuration options. Just makes it easier when a non-standard
configuration option has to be used.

Besides, I've also seen many Drupal sites with this problem. I suspect
that some of those sites would have implemented these flags if they had
been an option in the .htaccess file.  And it looks bad. People that
visit the sites that don't know any better will assume it's Drupal, not
the lack of proper PHP settings.


Tue, 08 Jun 2004 10:39:27 +0000 : killes at www.drop.org

It wouldn't hurt if Drupal had a better documented and possibly extended
.htaccess file.
Those who whish not to use it should really not care...

session.save_handler = user should probably included as well.


Tue, 08 Jun 2004 12:17:06 +0000 : robertDouglass

If you use these settings:
php_flag session.use_trans_sid off
php_flag session.use_only_cookies on

won't it make it so that people with cookies disabled cannot have
session state? And if the PHPSESSID is in the URL, isn't that an
indication that the browser being used refused to take a cookie? I'd
really like clarification on this, if anyone knows the answers.


Tue, 27 Jul 2004 13:25:46 +0000 : JonBob

The original issue is definitely by design, as these URLs need the
session ID to preserve the session when running under the given PHP
settings. A better-documented .htaccess is a different issue entirely.


Thu, 19 Aug 2004 18:04:13 +0000 : gtoddv

It hasn't been mentioned in this thread or anywhere else that I can
find, but this session ID issue breaks validation. I don't know is this
will cause accessibility issues too. I have tried the .htaccess fix and
that doesn't change anything.


Sat, 06 Nov 2004 07:17:21 +0000 : wazdog

The non-validating problem is another problem with your server setup.
PHP can be setup to used encoded &'s or not. Your server isn't if the
url isn't validating. You'd have to talk to your server admin to fix


Thu, 30 Dec 2004 20:32:35 +0000 : m_freeman2004

This is what you have to include in the .htaccess file:

# Fix for ?PHPSESSID in clean URLs
   php_value session.use_trans_sid 0
   php_value session.use_only_cookies 1
# End of fix


Wed, 01 Jun 2005 19:07:53 +0000 : dr05

The code in .htaccess file:
# Fix for ?PHPSESSID in clean URLs
php_value session.use_trans_sid 0
php_value session.use_only_cookies 1
# End of fix

don't work!
Error: "Internal Server Error!"


Thu, 14 Jul 2005 15:25:22 +0000 : jasonwhat

Anyone else looking into this?  Can one get rid of the id added onto the
url but still keep the sessions going?


Mon, 25 Jul 2005 06:16:22 +0000 : Eric Scouten

dr05, what version of Apache and what OS are you using? I've been using
this same patch with no problems on Mac OS X, Linux, and FreeBSD-based
servers using both Apache 1.3.x and 2.0.x.

Attached patch will apply these changes to .htaccess. (IMHO, this is
useful for the majority of users; those who are smart enough to
understand the performance issues can comment out these lines.)


Mon, 25 Jul 2005 06:57:18 +0000 : clydefrog

You forgot the patch, Eric.


Mon, 25 Jul 2005 08:02:26 +0000 : Eric Scouten

Attachment: http://drupal.org/files/issues/htaccess-no-session-ids.patch (383 bytes)



Mon, 25 Jul 2005 08:45:48 +0000 : kbahey

There are cases where no parameter will fix this issue. On shared
hosting systems where you do not have access to php.ini, and the
hosting company has setup things in a way that they cannot be

I found this out the hard way, after lobbying for the settings to be
included in the init_set() statements in the settings.php prior to 4.6
being released. They are simply ignored on some hosts. On other hosts,
you need to have a php.ini of your own, if suphp or SuExec is being

In some cases, the only way to make things work is to compile your own
PHP as a CGI (detailed writeup) [3]. This can have disadvantages too,
such some performance impact, as well as excessive CPU utilization
(hosting company may not like it).


Mon, 25 Jul 2005 08:49:31 +0000 : kbahey

Here is some references: issue 21170 [4], and a forum discussion [5].
[4] http://drupal.org/node/21170
[5] http://drupal.org/node/17947


Sat, 30 Jul 2005 16:24:47 +0000 : ufku

in my case (shared hosting, ini_set() disabled) a php.ini file with only
this line in it solved the problem.
url_rewriter.tags = ''
you should place the php.ini in your site's base directory


Sun, 07 Aug 2005 12:18:31 +0000 : djnz

Attachment: http://drupal.org/files/issues/rewrite_tags.patch (468 bytes)

Drupal already attempts to change a number of values using ini_set() in
settings.php, including session.use_trans_sid which should cure this
problem. Unfortunately as already noted elsewhere [6],
session.use_trans_sid only worked in ini_set() up to PHP 4.2.3.

Rather than change the whole philosophy and change this setting in
.htaccess or php.ini (neither of which work for many hosted set-ups),
surely the answer is to correct settings.php as described

The attached patch does just that - it is only one line.

Note that session ids are still appended to the url when redirecting by
Drupal eg after a POST. This is also easily patched [7], but as it is
done deliberately (why?) I have left it alone.

[6] http://drupal.org/node/17947#comment-36339
[7] http://drupal.org/node/25852#comment-45111


Sun, 07 Aug 2005 13:26:17 +0000 : kbahey

PHPSESSIDs in the URL are a) ugly, b) negatively affects search engine
indexing, and most importantly, c) is a security risk that can enable a
malicious user to hijack your session.

We should work on a solution to eliminate this once and for all, and
for all configurations.

The current approach (putting some PHP parameters in settings.php, or
instructing users to change them in .htaccess or php.ini) has severe
shorcomings: Whatever we do, there are bound to be some configurations
that no amount of PHP parameters will cure.

Some hosts deny their users the ability to change some or all of the
above parameters.

I discovered this the painful way with many hosts I have used, and
friends and clients I have helped.

I think we need to rethink this whole session thing, in a way that we
are not dependant on idiosyncracies of various hosts and PHP

Perhaps attempt to set a DRUPAL cookie and not maintain a session
unless we are able to set it. This way we know that we will not have a
PHPSESSID in the URL. If we are not able to set the cookie, then we
allow only anonymous access that is sessionless..

I am not sure if that will work or not: what other options do we have


Sun, 07 Aug 2005 22:02:19 +0000 : djnz

I am convinced that ini_set('url_rewriter.tags','') is the answer. I
find it hard to believe that any host would go to the trouble to
disable this (not just a matter of setting compile time paramaters, you
would have to hack the PHP source; and why would they?) - certainly no
cPanel host I have used does.

The reason the code currently in settings.php doesn't work is not
because hosts disable it, it is because PHP does not support it. RTFM.


Sun, 07 Aug 2005 22:23:59 +0000 : djnz

Attachment: http://drupal.org/files/issues/trans_sid.patch (1.4 KB)

After further thought, there really is no point in appending the SID to
a redirect url, so the attached patch solves this problem too.

If anyone has a problem with session IDs in URLs after applying this
patch, I'll offer them free hosting myself. Maybe. ;)


Mon, 08 Aug 2005 03:14:41 +0000 : kbahey

You are right about the fact that the use of PHPSESSID in the URL on a
redirect is totally unnecessary. That line should be removed from the
base code altogether, there is no excuse for it.

As for url_rewriter.tags, I am not 100% sure, but I tried it with
someone who was facing difficulties, and it did not work as far as I
can recall.

In any case, your solution should go in base. It cannot hurt, unless
some host has disabled it.


Mon, 08 Aug 2005 20:09:40 +0000 : moshe weitzman

yeah, i think that is cruft.


Mon, 08 Aug 2005 21:15:29 +0000 : kbahey

Attachment: http://drupal.org/files/issues/common.inc-trans_sid.patch (759 bytes)

Actually, since the code in common.inc should not fiddle with PHPSESSID
in URL in the first place, why not junk that whole section of the code

A patch for common.inc is attached that removes this whole section. As
Moshe said, this is cruft.

More information about the drupal-devel mailing list