On Fri, Nov 30, 2018 at 10:18 AM Eric Covener <cove...@gmail.com> wrote:

> On Fri, Nov 30, 2018 at 11:00 AM William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >
> > The comment here makes no sense (unix, not windows). But the patch
> itself seems reasonable. There is a performance hit, but nothing compared
> to the call into stat/lstat. Other's opinions?
>
> Seems risky from regression POV.  Safer to map errno of ENAMETOOLONG
> to the APR_ENAMETOOLONG, in case APR_NAMEMAX is lower than actual
> limit at runtime.
>

Which is the current implementation;

/** @see APR_STATUS_IS_ENAMETOOLONG */
#ifdef ENAMETOOLONG
#define APR_ENAMETOOLONG ENAMETOOLONG
#else
#define APR_ENAMETOOLONG   (APR_OS_START_CANONERR + 3)
#endif

On Win32, in theory we can have longer 32k character file paths, but these
were capped at 8k out of buffer space and other practical considerations.
(This might be something to revisit in the future.) This correlates to your
concern about new (regressive) limitations applied to Unix, in that we
started with a saner limit and would only expand it, later on.

For the time being, I'm happy if we drop this submission, unless it is shown
that [l]stat on specific unix platforms will errors other than ENAMETOOLONG
in response to such calls. My quick review of linux suggests it is fine
as-is,
as you suggested above.

Not sure about httpd patch though, IIUC it only helps a faulty config
> or module (dirwalk happening for long URI that won't actually be
> served off disk)
>

But it is well understood that we can't remove the filesystem module,
because it isn't modularized. I'm also not entirely comfortable with the
httpd patch, but the not-found reaction isn't nonsensical (it isn't a file,
so how would other modules like to behave?)

Reply via email to