Mailing List Archive

mod_proxy / mod_ssl interworking
PR on trunk, for review and commenting: https://github.com/apache/httpd/pull/190

This change makes it possible to have more than one SSL module handling proxy connections. The intention is to do this in a backward compatible way, like the previous ap_ssl_* changes.

The addition of a `conn_rec->outgoing` flag, set for these connections, makes it easy for any connection handling code to filter on the types of connections it is interested in.

Our test suite runs fine with these changes.

Cheers, Stefan
Re: mod_proxy / mod_ssl interworking [ In reply to ]
> Am 01.06.2021 um 16:39 schrieb Stefan Eissing <stefan.eissing@greenbytes.de>:
>
> PR on trunk, for review and commenting: https://github.com/apache/httpd/pull/190
>
> This change makes it possible to have more than one SSL module handling proxy connections. The intention is to do this in a backward compatible way, like the previous ap_ssl_* changes.
>
> The addition of a `conn_rec->outgoing` flag, set for these connections, makes it easy for any connection handling code to filter on the types of connections it is interested in.
>
> Our test suite runs fine with these changes.

He said while Travis is still running...optimistic as always...
Re: mod_proxy / mod_ssl interworking [ In reply to ]
On 01/06/2021 16:40, Stefan Eissing wrote:
>
>
>> Am 01.06.2021 um 16:39 schrieb Stefan Eissing <stefan.eissing@greenbytes.de>:
>>
>> PR on trunk, for review and commenting: https://github.com/apache/httpd/pull/190
>>
>> This change makes it possible to have more than one SSL module handling proxy connections. The intention is to do this in a backward compatible way, like the previous ap_ssl_* changes.
>>
>> The addition of a `conn_rec->outgoing` flag, set for these connections, makes it easy for any connection handling code to filter on the types of connections it is interested in.
>>
>> Our test suite runs fine with these changes.
>
> He said while Travis is still running...optimistic as always...
>

https://github.com/apache/httpd/pull/190/commits/867fa126f21575f104a1717ac49eaf1d8a558d77#diff-5506c76bad00bf136938033783d8d966bc463de54a679d3a8a390621b7a793c1R131

Should that be filled "automagically"?

--
Cheers

Jean-Frederic
Re: mod_proxy / mod_ssl interworking [ In reply to ]
> Am 01.06.2021 um 18:21 schrieb jean-frederic clere <jfclere@gmail.com>:
>
> On 01/06/2021 16:40, Stefan Eissing wrote:
>>> Am 01.06.2021 um 16:39 schrieb Stefan Eissing <stefan.eissing@greenbytes.de>:
>>>
>>> PR on trunk, for review and commenting: https://github.com/apache/httpd/pull/190
>>>
>>> This change makes it possible to have more than one SSL module handling proxy connections. The intention is to do this in a backward compatible way, like the previous ap_ssl_* changes.
>>>
>>> The addition of a `conn_rec->outgoing` flag, set for these connections, makes it easy for any connection handling code to filter on the types of connections it is interested in.
>>>
>>> Our test suite runs fine with these changes.
>> He said while Travis is still running...optimistic as always...
>
> https://github.com/apache/httpd/pull/190/commits/867fa126f21575f104a1717ac49eaf1d8a558d77#diff-5506c76bad00bf136938033783d8d966bc463de54a679d3a8a390621b7a793c1R131
>
> Should that be filled "automagically"?

How would you advise in filling that out before I commit to trunk?
Re: mod_proxy / mod_ssl interworking [ In reply to ]
On 01/06/2021 19:37, Stefan Eissing wrote:
>
>
>> Am 01.06.2021 um 18:21 schrieb jean-frederic clere <jfclere@gmail.com>:
>>
>> On 01/06/2021 16:40, Stefan Eissing wrote:
>>>> Am 01.06.2021 um 16:39 schrieb Stefan Eissing <stefan.eissing@greenbytes.de>:
>>>>
>>>> PR on trunk, for review and commenting: https://github.com/apache/httpd/pull/190
>>>>
>>>> This change makes it possible to have more than one SSL module handling proxy connections. The intention is to do this in a backward compatible way, like the previous ap_ssl_* changes.
>>>>
>>>> The addition of a `conn_rec->outgoing` flag, set for these connections, makes it easy for any connection handling code to filter on the types of connections it is interested in.
>>>>
>>>> Our test suite runs fine with these changes.
>>> He said while Travis is still running...optimistic as always...
>>
>> https://github.com/apache/httpd/pull/190/commits/867fa126f21575f104a1717ac49eaf1d8a558d77#diff-5506c76bad00bf136938033783d8d966bc463de54a679d3a8a390621b7a793c1R131
>>
>> Should that be filled "automagically"?
>
> How would you advise in filling that out before I commit to trunk?
>

I was thinking of telling this build something like ignore the PR it is
for review but that is too complex for nearly no benefits. Sorry for
noises.

--
Cheers

Jean-Frederic
Re: mod_proxy / mod_ssl interworking [ In reply to ]
> Am 02.06.2021 um 13:29 schrieb jean-frederic clere <jfclere@gmail.com>:
>
> On 01/06/2021 19:37, Stefan Eissing wrote:
>>> Am 01.06.2021 um 18:21 schrieb jean-frederic clere <jfclere@gmail.com>:
>>>
>>> On 01/06/2021 16:40, Stefan Eissing wrote:
>>>>> Am 01.06.2021 um 16:39 schrieb Stefan Eissing <stefan.eissing@greenbytes.de>:
>>>>>
>>>>> PR on trunk, for review and commenting: https://github.com/apache/httpd/pull/190
>>>>>
>>>>> This change makes it possible to have more than one SSL module handling proxy connections. The intention is to do this in a backward compatible way, like the previous ap_ssl_* changes.
>>>>>
>>>>> The addition of a `conn_rec->outgoing` flag, set for these connections, makes it easy for any connection handling code to filter on the types of connections it is interested in.
>>>>>
>>>>> Our test suite runs fine with these changes.
>>>> He said while Travis is still running...optimistic as always...
>>>
>>> https://github.com/apache/httpd/pull/190/commits/867fa126f21575f104a1717ac49eaf1d8a558d77#diff-5506c76bad00bf136938033783d8d966bc463de54a679d3a8a390621b7a793c1R131
>>>
>>> Should that be filled "automagically"?
>> How would you advise in filling that out before I commit to trunk?
>
> I was thinking of telling this build something like ignore the PR it is for review but that is too complex for nearly no benefits. Sorry for noises.

No problem. It would be nice to have it clean, but allocating log numbers on suspicion seems not worth it.

Upon further testing with 2 ssl modules today, I discovered the need for some changes which I will push most likely later today.

Stefan