> Am 20.08.2020 um 11:35 schrieb Ruediger Pluem <rpl...@apache.org>:
>
>
>
> On 8/20/20 10:47 AM, Stefan Eissing wrote:
>>
>>
>>> Am 20.08.2020 um 10:01 schrieb Ruediger Pluem <rpl...@apache.org>:
>>>
>>>
>>>
>>> On 8/19/20 12:18 PM, Stefan Eissing wrote:
>>>>
>>>>
>>>>> Am 19.08.2020 um 12:08 schrieb Ruediger Pluem <rpl...@apache.org>:
>
>>
>> Understood. I do not see 2. descending from the heavens either and I myself
>> am unable/unwilling to work on this.
>>
>> About hacking this somehow, the options I saw:
>>
>> a) do the header checking once the request_rec is created and scheduled on a
>> secondary connection in a separate thread
>> - this means we need to take the billions of header lines into out memory
>> first and then schedule a worker to reject it. Seems like begging for a DoS.
>> b) create a request_rec on the main connection, trigger the fail on the main
>> thread and hope that the response can be buffered and will not block the
>> whole h2 handling. Also begging for a DoS.
>> c) rewrite the error response handling in the server, which most likely we
>> will not be able to port back to 2.4
>>
>> Neither of those is attractive in my eyes. Maybe you see another way?
>
> What about:
>
> set_error_response would set the http_status in a not yet existing field
> (e.g. early_status)
> of the h2_request struct via stream->rtmp instead of creating a brigade in
> stream->out_buffer and adding to it.
> h2_request_create_rec could then check for this field and if non zero call
> ap_die after doing some minimal request_rec setup.
> I could transform this into a patch for more gory discussion if you like.
;-)
a) without making the complete requests, but a special one that knows how to
fail? Go for it!
cheers, Stefan
