mahara-contributors team mailing list archive

[Aaron Wells <1446036@xxxxxxxxxxxxxxxxxx>]

After discussing this with Robert and some other folks, here are my
conclusions:

1. For Mahara 15.10dev, we raise the minimum required PHP version to
5.4.

2. For Mahara 15.04, we keep it at 5.3 (so that we don't strand anyone
who upgraded their Mahara to 15.04.0)

3. In 15.04.1, we add the PHP 5.4 code that uses SessionHandler to
directly manipulate the session without calling session_start(). We put
a wrapper around this that only calls the code if you have PHP 5.4
installed.

4. For the people who are on 15.04.1 and still on PHP 5.3, we just stop
switching the sessions on and off. This means that the AJAX block loader
will load blocks one at a time instead of in parallel, and it will also
mean that the experimental bulk CSV exporter progress bar won't update
in real-time, but neither of those is a showstopper.

-- 
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