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.
Regards
Rüdiger
