[TYPO3-dev] Reinventing getIndpEnv() to support reverse proxys + SSL proxys

[Henning Pingel]

Hi,

For those quick readers without much time I will give a short summary of
what I want, before anybody get's too bored: ;-)

1) I want to create an extension for reverse proxy support including SSL
proxy support to make my reverse proxy patch available for testing
purposes for many people.
2) I need a hook for that in class.t3lib.div.php, or instead of that: I
would like to extract the content of function getIndpEnv() to an all new
php class.

End of summary. To understand the background of my thoughts please read
on. ;-)

Maybe some of you remember that I started working on enabling enable SSL
proxy support for TYPO3: One year ago I posted on this list about it,
then I read all the related bugtracker bugs (0000169, 0000202, 0001699,
0007397) and wrote some documentation about it including a patch for
class.t3lib.div.php [1].

To my surprise I got some positive feedback from other people who tested
my patch and were generally quite satisfied with it. So I'm wondering
what to do next to proceed with this project.

The most important things I learned so far are:

1) There are at least two solutions to have TYPO3 working with reverse
proxies:
a) Use a virtual host with some mod_rewrite rules (This is not the way I
want to go for several reasons.)
b) Change the coding in class.t3lib.div.php in function getIndpEnv().

2) Planning SSL proxy support means generally thinking about reverse
proxy needs, meaning: General support for reverse proxies.

3) Different proxy servers behave differently [2], so I concentrated on
Apache/mod_proxy, which should be the most popular scenario for an SSL
proxy. (Squid and Varnish are hardly used as SSL proxies, just as
ordinary reverse proxies).

4) My patch works quite well, but the code of the patch is not written
according to the CGLs. It can't be part of the TYPO3 core like it is now.

The scenario is like this: I think the patch must be tested by more
people in different setups, because it is likely that there are more
features to consider / more problems to be solved.

So my question is: How can I offer this new core functionality to more
people for further testing? I think the solution is to offer a reverse
proxy TYPO3 extension. I know that reverse proxy support is basically
core functionality, but unless it works properly it shouldn't be part of
the core.

To be able to create an extension I at least need a hook at the end of
function getIndpEnv(), which could look like this:

// check for custom mods of getIndpEnv (for example for reverse proxy or
ssl proxy)
global $TYPO3_CONF_VARS;
if
(is_array($TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_div.php']['getIndpEnv']))
{
    $params = array('getEnvName' => $getEnvName, 'retVal'=> $retVal);
    $fakeThis = FALSE;
    foreach
($TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_div.php']['getIndpEnv']
as $hookMethod)	{
        $retVal =
t3lib_div::callUserFunction($hookMethod,$params,$fakeThis);
        $params['retVal'] = $retVal;
    }
}

But I also think that it could be the right moment to outsource the
functionality of getIndpEnv() to an own new php class, because the
function get's less and less tidy. For compatibility reasons there could
still be a function getIndpEnv() in class.t3lib_div.php, but it will
only call methods of the new class.

Why do I see the need for an own class? Because reverse proxy support
requires a lot of changes in getIndpEnv(). I'll try to explain that:

Function getIndpEnv() passes on the values of server variables to the
caller, including special TYPO3 related vars like for example TYPO3_SSL.
>From the whole bunch of existing server variables (see phpinfo() for
details), function getIndpEnv() provides a "special treatment" for 21
variables to make TYPO3 work smoothly with different web servers. Those
variables are:

    HTTP_HOST
    TYPO3_HOST_ONLY
    TYPO3_PORT
    PATH_INFO
    QUERY_STRING
    REQUEST_URI
    HTTP_REFERER
    TYPO3_REQUEST_HOST
    TYPO3_REQUEST_URL
    TYPO3_REQUEST_SCRIPT
    TYPO3_REQUEST_DIR
    TYPO3_SITE_URL
    TYPO3_SITE_SCRIPT
    TYPO3_SSL
    SCRIPT_NAME
    TYPO3_DOCUMENT_ROOT
    SCRIPT_FILENAME
    REMOTE_ADDR
    REMOTE_HOST
    HTTP_USER_AGENT
    HTTP_ACCEPT_LANGUAGE

To enable SSL / reverse proxy support I need to change at least the
"special treatment" for 9 of these 21 variables. Those are:

    HTTP_HOST
    SCRIPT_NAME
    REQUEST_URI
    HTTP_REFERER
    TYPO3_REQUEST_HOST
    TYPO3_SSL
    TYPO3_HOST_ONLY
    TYPO3_PORT
    REMOTE_ADDR

Details regarding what to do with these variables are explained in my
tutorial [3].
This means touching and messing around with nearly half of the coding of
getIndpEnv() to integrate SSL proxy support. Therefore I think an own
class would mean much cleaner coding. It would also mean that we could
start buffering the values for faster access.

What do you think?

Cheers,
Henning

[1] http://www.henningpingel.de/TYPO3-Backend-Via-SSL-Proxy.124.0.html
[2] http://www.henningpingel.de/TYPO3-Backend-Via-SSL-Proxy.124.0.html#c334
[3] http://www.henningpingel.de/TYPO3-Backend-Via-SSL-Proxy.124.0.html#c299