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?
--- ./srclib/apr/file_io/unix/filestat.c 2007-10-17 00:36:49.000000000
-0300
+++ ./srclib/apr/file_io/unix/filestat.c 2008-06-11 22:26:50.000000000
-0300
@@ -279,6 +279,14 @@
struct_stat info;
int srv;
+ /* Catch fname length == MAX_PATH since GetFileAttributesEx fails
+ * with PATH_NOT_FOUND. We would rather indicate length error than
+ * 'not found'
+ */
+ if (strlen(fname) >= APR_PATH_MAX) {
+ return APR_ENAMETOOLONG;
+ }
+
if (wanted & APR_FINFO_LINK)
srv = lstat(fname, &info);
else
On Thu, Nov 29, 2018 at 2:34 PM Roman Garcia <romangarc...@gmail.com> wrote:
> Hi, sorry for the click-bait.
>
> Back in 2008 we notified Apache HTTP Server team about this
> <https://bz.apache.org/bugzilla/show_bug.cgi?id=45187> issue.
>
> Back then, I didn't realize this was (maybe, I'm assuming now) both an APR
> issue as an HTTPD issue.
>
> What we initially found was a HTTPD was returning FORBIDDEN for long URLs.
> Looking at the underlying code, we found HTTPD wasn't receiving context for
> too-long file paths.
>
> We did a change in APR to handle MAX_PATH cases on *NIX systems (it was
> already there in WIN32). Then we were able to add handling for those cases
> on HTTPD.
>
> Without a minimal idea of what APR stands for, or even its status
> regarding maintainance, I would imagine both *NIX and WIN32 any other OS
> should handle the file-path-too-long, and in the case of OSes like Linux
> you could go as far as to which FS manages the file to handle different
> limits.
>
> Would you guys agree the patch for APR is a valid one? Probably incomplete?
>
> Regards
> Roman
>
>
