> 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
- it seems counter-intuitive to construct and schedule a h1 request for
something that is not valid input
> 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.
As another example, see: https://github.com/icing/mod_h2/issues/203
> One approach I thought about is that 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 hack something up for more detailed discussion if this approach seems
> acceptable.
>
> BTW: Is the check for the field length in h2_stream_end_headers still needed
> as I think that h2_req_add_header called via
> h2_request_add_header by h2_stream_add_header already takes care of it?
Can't say without a closer look which I atm lack the time.
- Stefan
>
> Regards
>
> Rüdiger
