On Mon, Jun 8, 2020 at 10:12 PM Ruediger Pluem <[email protected]> wrote: > > On 6/8/20 10:05 PM, Yann Ylavic wrote: > > On Mon, Jun 8, 2020 at 9:30 PM Ruediger Pluem <[email protected]> wrote: > >> > >> On 6/8/20 4:59 PM, Yann Ylavic wrote: > >>> On Mon, Jun 8, 2020 at 9:56 AM Ruediger Pluem <[email protected]> wrote: > >>>> > >>>> I came across the question if we should not reject HTTP protocols >= 2.0 > >>>> in the request line when we parse it > >>>> in ap_parse_request_line. > >>> > >>> Why not >= 1.2 ? > >>> > >>>> A possible patch could look like the following (which rejects such > >>>> requests with a HTTP_VERSION_NOT_SUPPORTED status code): > >>> > >>> Looks good. > >>> > >>> > >>> In the same category, could we reject invalid URI paths earlier > >>> (request-target per RFC-7230 5.3)? > >>> Today it fails in ap_core_translate(), but possibly the below would be > >>> better: > >> > >> I think we could, but I am not sure if we have ap_parse_uri callers in > >> other parts of the code that do not pass absolute URI's > > > > This patch works with absolute URIs too since apr_parse_uri will split > > it in r->parsed_uri and we consider r->parsed_uri.path only. > > I guess I was not precise enough with my concern. I meant that I haven't > checked if there are callers which pass in relative URI's.
Oh no, actually _I_ missed the "do _not_ pass" :) I don't think ap_parse_uri() should accept an URI-path which is not HTTP compliant (i.e. does not start with '/'), that's where we initialize the request_rec after all.. So yes apr_uri_parse() accepts that and sets a relative path in r->parsed_uri.path, but ap_parse_uri() if for HTTP parsing IMHO. Regards; Yann.
