On Wed, Feb 9, 2022 at 11:28 AM Ruediger Pluem <rpl...@apache.org> wrote: > > On 2/9/22 10:28 AM, Stefan Eissing wrote: > > > >> Am 09.02.2022 um 10:15 schrieb Ruediger Pluem <rpl...@apache.org>: > >> > >> On 2/8/22 7:10 PM, Roy T. Fielding wrote: > >>> As noted in > >>> > >>> https://github.com/icing/mod_h2/issues/230#issuecomment-1032905432 > >>> > >>> This doesn't look right to me. I think what you want is to verify that > >>> https is > >>> in a secured connection. This should have no effect on other schemes, and > >>> certainly not require all schemes to be http or https. > >>> > >>> Literally, the scheme is a naming system, not a protocol. "http" and > >>> "https" > >>> and "foo" schemes can be resolved by any protocol that performs requests > >>> on an absolute URI, including HTTP/2. "https" only requires the connection > >>> to be secured end-to-end. > >> > >> With respect to our HTTP/1 handling r1895921 > >> http://svn.apache.org/viewvc?view=revision&revision=1895921 added > >> a check that the scheme for non forward proxied requests either needs to > >> be http or https, but we don't check > >> for a matching with the actual connection whether this is secured or not. > > > > Thanks for pointing that out, Ruediger. I think I need to change mod_http2 > > to > > populate the uri.scheme when a :scheme header was sent in the request. Then > > we have the check in one place. > > +1 in general, but we should check that :scheme does not contain characters > invalid for a scheme. > We likely would fail with invalid chars in the check of above revision, but I > would feel safer if we never have invalid chars in > uri.scheme :-)
Possibly we could build a full r->the_request in [1] if there is a :scheme, and let ap_parse_request_line() validate it. [1] https://github.com/apache/httpd/blob/trunk/modules/http2/h2_request.c#L298-L299 > > > > > The question with matching "http" and "https" concerns: > > A. do we select the correct server_rec matching the scheme? > > B. do we want to deny access to https: resources on a non-secured > > connection? > > > > I'll add a test for A. My opinion on B is that we should. > > There are probably setups behind SSL terminating LB's that will have the > scheme set to https while the request arrives over http > (from the LB). Hence I am not sure if we should require this and I don't want > to propose yet another configuration option to > disable this check for such cases. +1 Regards; Yann.
