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