Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: Re: mood_remoteip ProxyProtocol addition
To: dev@httpd.apache.org
References: <652f1f22-e0b5-5dfb-3baa-201ca364645d@hoentjen.eu>
 <CA+nBocAuOmr2v6=jU4ubmM+jR2HXu4_mHrVEFDD7vQP6QEnOmQ@mail.gmail.com>
 <CAKQ1sVOXJpgPiBRcCH5ah_MkxovWRM4W8yEQJhhU2ZcaN4o7sQ@mail.gmail.com>
 <CA+nBocACXzh5LDKCytOq2A3buUy-nZQJaO9X8_GW4+6uKuoezg@mail.gmail.com>
 <CAKQ1sVOC6Xze=+AtFrtwozKRrh3WpTLwHz9mqEHZP_R3ZU9uew@mail.gmail.com>
 <d4003978-0709-f7c5-8114-b744d9f718c4@thelounge.net>
 <CAKQ1sVOa5pr3jeN6x-=CVAFkN=NbsgJj_rF-hhqtjO_eFw=TvQ@mail.gmail.com>
 <debc4ce8-f5a3-8fad-74bd-ddff04be9cd6@thelounge.net>
 <CAKQ1sVPNxqcO5yX6GXOq-Q1A7xhD1fsQm_=f-pMELT4e80T6Jw@mail.gmail.com>
 <CAKQ1sVM=o_z4zFyH29-ZLznDnLZz9uYaDgTWPqYe=dPXepNwNA@mail.gmail.com>
From: Reindl Harald <h.reindl@thelounge.net>
Organization: the lounge interactive design
Message-ID: <f2468a88-7387-4f5c-644d-3bb733bb5262@thelounge.net>
Date: Wed, 8 Feb 2017 01:00:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CAKQ1sVM=o_z4zFyH29-ZLznDnLZz9uYaDgTWPqYe=dPXepNwNA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Wed, 08 Feb 2017 00:00:45 -0000


Am 08.02.2017 um 00:44 schrieb Yann Ylavic:
> On Wed, Feb 8, 2017 at 12:25 AM, Yann Ylavic <ylavic.dev@gmail.com> wrote:
>> On Wed, Feb 8, 2017 at 12:01 AM, Reindl Harald <h.reindl@thelounge.net> wrote:
>>>
>>> how can you trust as a php application developer that "X-Forwarded-Proto" is
>>> trustable and not from the enduser client at all - for REMOTE_ADDR you don't
>>> consider "X-Forwarded-For" exactly for that reason
>>
>> I'm not proposing to use or trust "X-Forwarded-Proto" directly, but
>> that mod_remoteip [either directly or provides the (optional)
>> functions for ap_add_{common,cgi}_vars() to] set REMOTE_HTTPS=on
>> and/or REMOTE_SCHEME=https accordingly.
>> Just like REMOTE_ADDR.
>>
>> But not change HTTPS and/or REQUEST_SCHEME (but more importantly their
>> sources/hooks as accessed and read by core/modules), like (IIUC)
>> proposed by the patches.
>> These are local informations.
>
> Actually, I'm not really opposed to set HTTPS=on (according to
> mod_remoteip) in the environment *given to the script/CGI* only, if
> that's the trigger for it to do the desired thing, this won't be used
> by httpd internally at least.
>
> What's proposed so far is much more than that (if I read the patches correctly)

ok, so finally we agree :-)

i am only interested in a centralized way to get rid of hacks like below 
in each and every application where mod_remoteip solves the similar 
problem with $_SERVER['REMOTAE_ADDR'] for cgi/mod_php

$_SERVER['REQUEST_SCHEME'] because you typically build a full qualifiied 
URL for a link in emails with $_SERVER['REQUEST_SCHEME'] . '//' . 
$_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'] . '?param=x'

in my own application the hack below was simple - in case of other 
software like Magento and so on you have to hack "index.php" while at 
the same time you should not touch the application code to keep it 
easily updateable

if(!empty($config['cms_tls_offload']))
{
  $_SERVER['SERVER_PORT']    = '443';
  $_SERVER['REQUEST_SCHEME'] = 'https';
  $_SERVER['HTTPS']          = 'on';
}