> 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>:
>>>
>>> If mod_http2 detects too many or too large request headers in
>>> h2_stream_add_header or h2_stream_end_headers it does not create a
>>> pseudo HTTP/1.1 request but directly responds back on the HTTP/2 stream.
>>> While this is very efficient from the HTTP/2 perspective
>>> it has some bad drawbacks from my perspective:
>>>
>>> 1. The request is not logged in the access log.
>>> 2. Possible custom ErrorDocuments for this status code
>>> (HTTP_REQUEST_HEADER_FIELDS_TOO_LARGE, 431) are ignored.
>>
>> The main reasons (as far as my memory serves) are:
>> - that at that time, the whole h1 infrastructure has not been set up yet.
>> - reporting on requests and error doc handling is only possible from h1
>
> This is my understanding as well.
>
>> - it seems counter-intuitive to construct and schedule a h1 request for
>> something that is not valid input
>
> I understand that from a developer perspective and as said I see the current
> flow as more efficient. On the other hand from a user
> perspective it is counter-intuitive if the "same" request behaves differently
> whether it is requested via HTTP/1.1 or via HTTP/2.
> In the first case it is logged and a custom error page if defined is
> returned, in the second case this does not happen.
I totally agree.
>>
>>> I would like to see this changed to have the drawbacks above addressed.
>>> Thoughts?
>>
>> Ceterum censeo: to make all features currently tied to h1 work for other
>> protocol, one needs to separate them into a "http" layer that is agnostic to
>> the serialization of requests/responses.
>
> Agreed, but what does this mean? I think we have two ways forward here:
>
> 1. We continue to hack around this limitation with better or worse hacks that
> repeat themselves.
> 2. We stop all changes that would require this layer until this layer is in
> place.
>
> While 2. is the cleaner way I doubt that the layer will be availabe any time
> soon. Hence 2. would mean to stop some further and
> maybe important work on the http2 module. Hence I tend to go for 1., but I am
> keen for other opinions or further options that I
> missed.
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?
- Stefan
