mahara-contributors team mailing list archive

[Aaron Wells <1446036@xxxxxxxxxxxxxxxxxx>]

On further research, it looks like directly manipulating the session
through SessionHandler isn't going to work. If you're using the default
session handler it causes a fatal error. If you're using a custom
session handler, like memcached, then it doesn't throw a fatal error,
but it doesn't seem to work as expected.

So we can ignore all the stuff in the preceding comment. We probably
should raise our minimum supported PHP version to 5.4, but not because
of this.

What I've done instead, is after each time we call session_start(), I
call a method that uses headers_list() and header_remove() to eliminate
the duplicate session cookies.

The behavior of PHP in this regard is a bit buggy. When there are
duplicate session cookies that are going to be sent out, it still only
shows one copy of the session cookie when you call headers_list().
However, doing "header_remove('Set-Cookie')" will remove all of the
session cookie headers (as well as all the other cookies). So what I do
is use headers_list() to get a list of all the unique cookies, do
header_remove('Set-Cookie'), and then use header() to add each cookie
header back.

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1446036

Title:
  Session changes in Mahara 15.04 can cause excessively large response
  headers

Status in Mahara ePortfolio:
  Confirmed
Status in Mahara 15.04 series:
  Confirmed
Status in Mahara 15.10 series:
  Confirmed

Bug description:
  For the new Ajax progress bar, Bug 1352028, we changed
  htdocs/auth/session.php so that it closes the PHP session when not in
  use. This was necessary in order to allow multiple requests to the
  same session to process simultaneously; PHP by default locks the
  session between the time you call session_start() and
  session_write_close().

  The downside to this approach, though, is that every time you call
  session_start(), PHP adds a new (duplicate) PHP_SESS_ID cookie to the
  request header. Since we open and close the session every time we call
  $SESSION->set() now, this can lead to a very large cookie header. (See
  https://bugs.php.net/bug.php?id=38104 )

  On our hosting environment, these headers got too large and started
  causing our Nginx proxy server to throw errors while trying to
  initiate an MNet connection. This causes the proxy server to throw a
  500 error, and to log an error like this:

  2015/04/20 14:59:03 [error] 14845#0: *137093286 upstream sent too big
  header while reading response header from upstream, client:
  2404:130:0:1000:61f4:7e47:8a26:821, server: master-
  mahara.catalystdemo.net.nz, request: "GET
  /auth/xmlrpc/land.php?token=3acfeeb7cad9814471ec5932fc293b30bbc7e387&idp=http
  ://mnet-moodle.testing.elearning.catalyst.net.nz&wantsurl= HTTP/1.1",
  upstream:
  "http://202.78.243.12:9226/auth/xmlrpc/land.php?token=3acfeeb7cad9814471ec5932fc293b30bbc7e387&idp=http
  ://mnet-moodle.testing.elearning.catalyst.net.nz&wantsurl=", host:
  "master-mahara.catalystdemo.net.nz"

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1446036/+subscriptions