Bug 45187 - Long File name requests gives FORBIDDEN response
Summary: Long File name requests gives FORBIDDEN response
Status: REOPENED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.4.7
Hardware: PC Linux
: P1 major with 24 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate, PatchAvailable
Depends on:
Blocks:
 
Reported: 2008-06-11 18:51 UTC by Roman Garcia
Modified: 2020-04-10 11:09 UTC (History)
5 users (show)



Attachments
Long Filenames Patch (1.14 KB, patch)
2008-06-11 18:51 UTC, Roman Garcia
Details | Diff
long filenames 404 patch (1.41 KB, patch)
2020-01-29 22:27 UTC, Giovanni Bechis
Details | Diff
return 404 on too long filenames (1.39 KB, patch)
2020-04-10 11:00 UTC, Giovanni Bechis
Details | Diff
return 404 on long filenames (1.39 KB, patch)
2020-04-10 11:09 UTC, Giovanni Bechis
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Garcia 2008-06-11 18:51:43 UTC
Created attachment 22112 [details]
Long Filenames Patch

Hi, I'm currently working for a huge e-commerce dev team, and we've been having errors with long URLs in apache.

For some reason, GETting the following URL (323 chars long):
http://my-server.com.ar/celulares_isNcaracteristica-camara-telefono-movilZcaracteristica-camara-telefono-movil--nd--_isNmodelo-telefono-movilZmodelo-telefono-movil--nd--_isNproveedor-servicio-telefoniaZproveedor-servicio-telefonia--nd--_isNtecnologia-telefono-movilZtecnologia-telefono-movil--nd--_isNtipo-telefono-movilZtipo-telefono-movil--nd--
Apache replies a 403 - HTTP_FORBIDDEN, and in the log file we found:

[Wed Jun 11 13:48:50 2008] [error] [client 127.0.0.1] (36)File name too long: access to /celulares_isNcaracteristica-camara-telefono-movilZcaracteristica-camara-telefono-movil--nd--_isNmodelo-telefono-movilZmodelo-telefono-movil--nd--_isNproveedor-servicio-telefoniaZproveedor-servicio-telefonia--nd--_isNtecnologia-telefono-movilZtecnologia-telefono-movil--nd--_isNtipo-telefono-movilZtipo-telefono-movil--nd-- failed.

BUT, if I prepend a "directory" to that exact same URL, like the following:
http://my-server.com.ar/sample_directory/celulares_isNcaracteristica-camara-telefono-movilZcaracteristica-camara-telefono-movil--nd--_isNmodelo-telefono-movilZmodelo-telefono-movil--nd--_isNproveedor-servicio-telefoniaZproveedor-servicio-telefonia--nd--_isNtecnologia-telefono-movilZtecnologia-telefono-movil--nd--_isNtipo-telefono-movilZtipo-telefono-movil--nd--
it works OK!

After looking thru the source code, I've found that there are a few places where a call to the OS is made to retrieve file info, which seems to raise an error when the file name is longer than that supported. And for those cases, it replied with a FORBIDDEN status.

SOLUTION (?):
What I decided to do was to change a few lines so for those cases, we react the same as if that file DIDN'T EXIST. Long story short: before going for the OS to retrieve file information, I check if the file name is longer than that supported. If it is, I reply with an APR_ENAMETOOLONG code. And then, on request.c I mark the request:
thisinfo.filetype = APR_NOFILE;

I'm attaching the diff for this patch. Please let me know if this is a valid solution to my problem, or if this could raise any other issues.
Thanks,
Román.
Comment 1 Nick Kew 2008-06-12 03:09:08 UTC
You've marked this Windows XP, but your patch applies to Unix code.  Please clarify.

Also, calling it 'critical' seems way OTT.
Comment 2 Roman Garcia 2008-06-12 07:32:24 UTC
Ok. This bug reproduces both in XP AND Linux.
They both reply a 403-FORBIDDEN. But the log shows different errors on XP.
I guess this is no one catching the OS error. 

Anyway, I bet all OSs have long filenames limitations, so you guys might wanna check them all!

I changed it to Major severity. You're welcome!

Oh! BTW, the patch I provided applies to 2.2.8 only!
Thanks
R
Comment 3 Jeff Trawick 2008-06-12 08:16:39 UTC
possibly the actual URLs you're having problems with are not getting passed to your application properly, such that Apache ends up trying to map the file to disk and as part of that find out that the file doesn't exist

what module is supposed to handle these requests?  is it smart enough to bypass Apache's logic to try to find a matching file on disk?

its not really anybody's business which filenames are too long for the filesystem Apache runs from, and it isn't a valid file request anyway, so forbidden seems fine
Comment 4 Roman Garcia 2008-06-12 09:05:11 UTC
(In reply to comment #3)
> possibly the actual URLs you're having problems with are not getting passed to
> your application properly, such that Apache ends up trying to map the file to
> disk and as part of that find out that the file doesn't exist

I'm not really sure. I'm not that much into Apache's code.
What I know is:
The URL never gets to my application. It doesn't even get to the "rewrite" module.
Only with the provided patch, Apache now seems to send the URL to other modules, included rewrite and mod_jk. This error happens "before" passing the URL to my application.


> what module is supposed to handle these requests?  is it smart enough to bypass
> Apache's logic to try to find a matching file on disk?

There's no module affecting this behaviour. As stated before, AFAIK, the request doesn't get THAT far.

> 
> its not really anybody's business which filenames are too long for the
> filesystem Apache runs from, 

I agree. It's Apache's business only.

> and it isn't a valid file request anyway, so
> forbidden seems fine
> 
I disagree. 
Ok, it's not a "valid" file request, since it's not an existent file on the filesystem. But still it is a valid URL. And as any other valid URL, it should get to other modules to process it.

For what I've seen, unexistent files have a special condition (from request.c:954):
   if (APR_STATUS_IS_ENOENT(rv))

My question is, if the underlying FS cannot store the given file, because it's filename is too long, doesn't that simply mean that the file doesn't exist? Couldn't (shouldn't) Apache treat both cases the same?

In case more info is needed here, this issue appeared on:
Apache 2.2.4 running on Ubuntu 8.04.
Apache 2.2.4 running on WinXP SP2.
Modules loaded (defaults?):
LoadModule actions_module modules/mod_actions.so
LoadModule alias_module modules/mod_alias.so
LoadModule asis_module modules/mod_asis.so
LoadModule auth_basic_module modules/mod_auth_basic.s
LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authz_default_module modules/mod_authz_default.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule deflate_module modules/mod_deflate.so
LoadModule dir_module modules/mod_dir.so
LoadModule env_module modules/mod_env.so
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
LoadModule imagemap_module modules/mod_imagemap.so
LoadModule include_module modules/mod_include.so
LoadModule isapi_module modules/mod_isapi.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule userdir_module modules/mod_userdir.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule jk_module modules/mod_jk-apache-2.2.4.so

Thank you!
Román
Comment 5 Jeff Trawick 2008-06-12 11:25:55 UTC
A higher-level concern here is that your backend requests are triggering a filesystem check by Apache; if that were bypassed, the filesystem limitation which led to 403 wouldn't be encountered, and be more efficient.

It looks like mod_proxy_ajp bundled with Apache 2.2 would skip the filesystem checks, but I haven't tested that.  I don't know the state of mod_jk, or if the jk configuration affects this.

(Jopefully somebody with time to see how to make your request work with mod_jk will chime in ;) )
Comment 6 Roman Garcia 2008-06-12 12:03:29 UTC
(In reply to comment #5)
> A higher-level concern here is that your backend requests are triggering a
> filesystem check by Apache; if that were bypassed, the filesystem limitation
> which led to 403 wouldn't be encountered, and be more efficient.
> 
> It looks like mod_proxy_ajp bundled with Apache 2.2 would skip the filesystem
> checks, but I haven't tested that.  I don't know the state of mod_jk, or if the
> jk configuration affects this.
> 
> (Jopefully somebody with time to see how to make your request work with mod_jk
> will chime in ;) )
> 

Jeff, just to be sure. 
Are you saying I could somehow bypass this filesystem check using some bundled module? Could anyone else confirm this? Did anyone test this?
Actually, is there any internal configuration I could add to skip this check?

I mean, I'm not sure at what point of the flow this happens, but it looked like the very beginning of the request handling...doesn't look like a mod could help me here. But then again...only you guys know that! :)

Thanks,
Román.



Comment 7 William A. Rowe Jr. 2008-06-12 12:44:02 UTC
Yes.

The filename testing occurs in the "directory walk".  Any module which
is configured to avoid this altogether, e.g. mod_proxy using ProxyPass
redirection, should dodge the filename testing.

That's not how mod_jk works, but you should try mod_proxy_ajp as a suitable
replacement which should solve your issue, provided you don't encounter similar
problems on Tomcat.

Since reading the thread, and the fact that you are the first app designer
to complain, I'd suggest a review of your design parameters to come up with
URI paths that aren't so excessively long.  There may even be issues on the
client side with paths such as these.
Comment 8 Roman Garcia 2008-06-12 13:50:57 UTC
(In reply to comment #7)
> Yes.
> 
> The filename testing occurs in the "directory walk".  Any module which
> is configured to avoid this altogether, e.g. mod_proxy using ProxyPass
> redirection, should dodge the filename testing.
> 
> That's not how mod_jk works, but you should try mod_proxy_ajp as a suitable
> replacement which should solve your issue, provided you don't encounter similar
> problems on Tomcat.

I will try the mod_proxy_ajp to see if that solves OUR problem. 
But still, that won't solve Apache's problem.
For whatever reason, Apache does check the filesystem to see if a given file is there. And FORBIDDEN is not a valid response to that question.

I guess what confuses me the most is you guys don't seem to consider this issue as a bug. Is FORBIDDEN a valid answer to a long URI request?

> Since reading the thread, and the fact that you are the first app designer
> to complain, I'd suggest a review of your design parameters to come up with
> URI paths that aren't so excessively long.  There may even be issues on the
> client side with paths such as these.

Even if I could change requirements (which I can't), I wouldn't only to adjust them to an existing bug.
Also, I don't consider 400 chars excessively long. Specially when even worst browsers, IE that is, support more than 2048 chars long
http://support.microsoft.com/kb/q208427
Opera & Firefox support more than 10k chars for URLs I believe...

If the problem is "how many app designers complain", just let me know so I can collect signatures for a "formal request". Just tell me how many app designers do you need. ;)
Comment 9 Jeff Trawick 2008-06-12 14:09:27 UTC
>I guess what confuses me the most is you guys don't seem to consider this issue
>as a bug. Is FORBIDDEN a valid answer to a long URI request?

It wouldn't help you if we returned error 404 instead of 403.  Your non-filesystem requests need to bypass this filesystem logic.

This isn't the place to decide that this isn't a filesystem request; the module handling the request (mod_jk in your case) should have indicated that at an earlier stage.

Comment 10 Ruediger Pluem 2008-06-12 14:26:20 UTC
(In reply to comment #7)
> Yes.
> 
> The filename testing occurs in the "directory walk".  Any module which

And this happens *after* applying the server wide mod_rewrite rules (not the
ones configured per directory or in .htaccess) So it is quite astonishing that the reporter says that the request does not even hit his rewrite rules.

> is configured to avoid this altogether, e.g. mod_proxy using ProxyPass
> redirection, should dodge the filename testing.
> 
> That's not how mod_jk works, but you should try mod_proxy_ajp as a suitable
> replacement which should solve your issue, provided you don't encounter similar
> problems on Tomcat.

mod_jk (1.2.26) also should not hit the "directory walk" as it has its own map_to_storage hook handler that stops the processing of the hook before
the directory walk if a valid mapping for the uri was found.

So all the above increases my feeling that the server is simply misconfigured
and that this is the reason why the request does not get to the application.

Second point is that that ENAMETOOLONG IMHO does not necessarily mean that the file does not exist (this would be indicated by ENOENT IMHO). It seems to indicate that path supplied to the stat call is too long which would open up
the possibility to change to the appropriate directory and do a local stat
there. Since httpd does not do this it smells something suspicious here and
returns FORBIDDEN which is ok in this situation. BTW: Replying with not found also could drive the user of httpd nuts if the file is present.
And to be honest what I don't get is: Does it really matter if you get FORBIDDEN or NOT FOUND. In both cases you do not get the file and this is not what you want an expect. You expect your content to be delivered.



Comment 11 Roman Garcia 2008-06-12 15:51:27 UTC
I guess if our Apache was misconfigured, we would have noticed it earlier. We've been running this configuration for more than 5 years now. But it could be an option.

I'm trying to understand here. Are you saying that there is a way to skip filesystem access? Even with mod_jk? Can you point me out some documents I can read for that? Examples on how to setup mod_jk to skip the FS?

If that's the case, and the only reason Apache is accesing the FS is because it KNOWS for fact that the user is requesting a FS file (because it ruled out any other possibilities), then FORBIDDEN or whichever response you choose for this should be fine.
But, if this is the case, then why does Apache check for ENOENT at that point and what does it do with that request, when the file was not found? Why doesn't it just reply a 404 right there?

On the other hand, if Apache reacts this way WITHOUT KNOWING whether the user is requesting an FS file, a SymLink, or a virtual path, then that's simply wrong.
Because this is my case, because we hit an URL which gets rewritten, which gets passed to a Tomcat, which is handled by a Java app. Which, BTW, works OK with the patch I submitted.

I guess this could be easily tested, with a proper environment.
It should be as simple as:
Install Apache
Do a GET for a long URL.
Check the log

Anyone wanna give it a try? ;)

Román.
Comment 12 mark 2008-09-24 08:38:32 UTC
FYI I encounter this exact problem with mod_python as well.

Apparently mod_python does not bypass the directory walk.
Comment 13 Nick Kew 2008-12-31 11:54:04 UTC
FWIW, I think the best HTTP response in this case should be 400.

404 is worse than 403 (it may be correct, but it's misleading if wrong).  414 would be another candidate, but could also lead to misleading/inconsistent results.

Changing it to return 400 would be a trivial patch to request.c, if anyone agrees with my suggestion.
Comment 14 maca 2009-03-12 08:15:14 UTC
I agree with Roman. This is a bug and bug should be corrected. The server should not look for a file, when the URL is obviously not a file. File Not Found - is the right response for such request.
Comment 15 DanielFird 2012-03-06 10:30:48 UTC
I have been suffering from accessing, managing and even renaming files that have more than 255 characters over a long time. I have tried various ways but failed. Then I have searched this problem in internet. Then I have found a solution. This software is very easy to use. Named Long path Tool.  To use the program all you need to do is to download this program online and save all the settings to your computer. This program is compatible with Windows NT, 2000, XP, Vista and Windows 7. you can find it from longpathtool(dot)com
Comment 16 Ryszard Łach 2013-09-17 20:08:13 UTC
Exactly. Returning forbidden only because the request file name is longer then 256B even if it does not have to be file name is a bug.

Does anybody know if the bug still exists in 2.4 ?
Comment 17 Ryszard Łach 2013-09-17 20:17:22 UTC
I've just checked in apache 2.4.6 - the bug is applicable too.
Comment 18 andre.tannus 2014-04-15 01:59:20 UTC
What is the latest news on this? Will it be fixed?
Comment 19 Eric Covener 2014-04-15 02:05:00 UTC
(needinfo means info is needed from the originator)
Comment 20 Hiep Pham 2014-05-08 02:21:50 UTC
I've been having this problem when working with apache 2.2.4 on MacOS Mavericks 10.9. Even when I updated apache to 2.4.9 (actually install new one) nothing has changed. Could you give me some suggestions?
Comment 21 Anton Voloshin 2014-05-08 09:23:09 UTC
(In reply to Hiep Pham from comment #20)
> Could you give me some suggestions?

I've ended up moving those mod_rewrite rules from .htaccess to apache config file, then suddenly this bug disappears. This is the only workaround I'm aware of. In my particular case those rules are (from /etc/apache/sites-enabled/sitename.com):
    <IfModule mod_rewrite.c>
        RewriteEngine on
        RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
        RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
        #nosubreq is needed to pass on internal subrequests: dir/ => dir/index.html
        RewriteRule ^/20[0-9][0-9]/[0-9][0-9]/([0-9]+) /news/index.php?id=$1 [nosubreq,QSA]
    </IfModule>

Those rules did not work in .htaccess with very long URIs (giving the infamous "403 forbidden") but they work just fine in the apache config file.

However, this is a real bug and it should be fixed.
Comment 22 Hiep Pham 2014-05-09 01:48:02 UTC
(In reply to Anton Voloshin from comment #21)
I've found a way shorten my URIs so that my problems all gone. Anyway, thank you very much, I'll try your solution later.

> However, this is a real bug and it should be fixed.

can not agree more :)
Cheers! ;)
Comment 23 Roman Garcia 2014-05-09 02:03:49 UTC
Did anyone try to apply the patch to the latest trunk version?
It's only 6 lines that need to be added...I believe the merge should be simple.

Just FYI, the patch I offered here is running today 6 years in production without an issue.
Comment 24 Hiep Pham 2014-05-09 02:19:22 UTC
The lastest trunk version doesn't have "./srclib/apr/file_io/unix/filestat.c" and I have no idea where it is (actually I'm too lazy to find it) :)
This bug only appears when I use Apache on MacOS, maybe they don't care about it because it's no longer applicable on Windows or Linux.
Comment 25 ernesto 2015-06-13 02:36:03 UTC
I think you need to try Long Path Tool on this situation. I hope that it helps.
Comment 26 Anshul 2016-01-25 13:25:57 UTC
I am facing the same issue.

Apache logs :

[2016-01-25T18:48:31.5980+05:30] [OHS] [ERROR:32] [OHS-9999] [core.c] [client_id: 10.87.152.136] [host_id: WCUATINFRA] [host_addr: 10.87.206.108] [tid: 10024] [user: oracle] [ecid: 000001blLQC4mnVLu2d9iX01K02Y00001s] [rid: 0] [VirtualHost: main] (86)File name too long:  Cannot map POST /CSSPortal/resourceproxy/~.portletId~3D~252Foracle~252Fadf~252Fportlet~252FWSRP~252Fap~252FLoginPortlet_7aab73f3_013f_1000_8001_0a4d30708e34~26clientId~3D1315943251~26resourceId~3Dwsrp-url~25253D~252526wsrp-resourceID~25253D_wlp-nullResId~252526wsrp-preferOperation~25253Dtrue~252526wsrp-requiresRewrite~25253D~252526wsrp-resourceState~25253DeJyLL07OL0i1zc1PSQ0GsVLUiooKbNXSc-KTEnNsAbM4C0U~252526wsrp-resourceCacheability~25253Dpage~252526wsrp-navigationalValues~25253D~252526oracle~2525253Arunnable-attribs~25253Doracle.portlet.newNavigationalContextScope~2525253Dtrue~25252526oracle.portlet.request.context.string.currentPagePath~2525253D~252525252Foracle~252525252Fwebcenter~252525252Fportalapp~252525252Fpages~252525252FCSSLogin.jspx~25252526oracle.adf.portlet.Stretched~2525253Dtrue~25252526oracle.portlet.request.context.string.currentPageName~2525253DCSSLogin.jspx~26baseUrl~3Dhttps~253A~252F~252Fmyvodafonesit.vodafone.in~252FCSSPortal~252Ffaces~252Foracle~252Fwebcenter~252Fportalapp~252Fpages~252FCSSLogin.jspx~253F_adf.ctrl-state~253D8ihv1i5j6_4~2526_afrLoop~253D121736612963976677~26locale~3Den~26checksum~3D40bc02cce3ffe09b2544145448ed393856a2b5e8/_wlp-nullResId HTTP/1.1 to file, referer: https://myvodafonesit.vodafone.in/CSSPortal/adfportlet?_adfp_request_id=748695f0-d211-4047-a29a-7aa0418e7cbc&_adfp_icr=1


Browser log :

"NetworkError: 403 Forbidden - https://myvodafonesit.vodafone.in/CSSPortal/resourceproxy/~.portletId~3D~252Foracle~252Fadf~252Fportlet~252FWSRP~252Fap~252FLoginPortlet_7aab73f3_013f_1000_8001_0a4d30708e34~26clientId~3D1315943251~26resourceId~3Dwsrp-url~25253D~252526wsrp-resourceID~25253D_wlp-nullResId~252526wsrp-preferOperation~25253Dtrue~252526wsrp-requiresRewrite~25253D~252526wsrp-resourceState~25253DeJyLL07OL0i1zc1PSQ0GsVLUiooKbNXSc-KTEnNsAbM4C0U~252526wsrp-resourceCacheability~25253Dpage~252526wsrp-navigationalValues~25253D~252526oracle~2525253Arunnable-attribs~25253Doracle.portlet.newNavigationalContextScope~2525253Dtrue~25252526oracle.portlet.request.context.string.currentPagePath~2525253D~252525252Foracle~252525252Fwebcenter~252525252Fportalapp~252525252Fpages~252525252FCSSLogin.jspx~25252526oracle.adf.portlet.Stretched~2525253Dtrue~25252526oracle.portlet.request.context.string.currentPageName~2525253DCSSLogin.jspx~26baseUrl~3Dhttps~253A~252F~252Fmyvodafonesit.vodafone.in~252FCSSPortal~252Ffaces~252Foracle~252Fwebcenter~252Fportalapp~252Fpages~252FCSSLogin.jspx~253F_adf.ctrl-state~253D8ihv1i5j6_4~2526_afrLoop~253D121736612963976677~26locale~3Den~26checksum~3D40bc02cce3ffe09b2544145448ed393856a2b5e8/_wlp-nullResId"
Comment 27 ronaldcarl06 2016-08-19 11:15:46 UTC
You can also checkout long path tool, it's an automated software for this type of errors
Comment 28 liona jackson 2017-04-05 08:28:51 UTC
I have recently used a program called Long Path Tool & i am so happy with the results that this particular program does. I have more than 50 GB of duplicate files in my computer and i was going crazy with the hard disk space that was being consumed and thanks to the "Long Path Tool" where i don't need to search each & every file to delete. Long Path Tool did the job for me within a very short period of time. So no need to google each problem to remove duplicate & unwanted files, just grab the program called Long Path Tool.
Comment 29 liona jackson 2017-04-20 10:10:45 UTC
In other words same situation was for me before but when i installed Long Path Tool, my computer was organized easily and i got relaxed from everyday files and junk.
Comment 30 William A. Rowe Jr. 2018-11-07 21:09:43 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.
Comment 32 Luca Toscano 2018-12-01 08:52:30 UTC
Hi Roman,

have you tried to modify http://httpd.apache.org/docs/2.4/mod/core.html#limitrequestline ?
Comment 33 Giovanni Bechis 2020-01-29 21:07:58 UTC
I think it fails in apr_filepath_get in apr/file_io/unix/filepath.c,
getcwd(3) fails with ERANGE because the specified path is longer than PATH_MAX (as defined in limits.h of your os).
Comment 34 Roman Garcia 2020-01-29 21:32:39 UTC
(In reply to Luca Toscano from comment #32)
> Hi Roman,
> 
> have you tried to modify
> http://httpd.apache.org/docs/2.4/mod/core.html#limitrequestline ?

Not sure if I did, but think it didn't get as far as checking a request-line limit. The error, 12 years ago, was related to HTTPd trying to stat the FS for a file which failed for the file path length being over what the FS supported.
Comment 35 Roman Garcia 2020-01-29 21:37:36 UTC
(In reply to Giovanni Bechis from comment #33)
> I think it fails in apr_filepath_get in apr/file_io/unix/filepath.c,
> getcwd(3) fails with ERANGE because the specified path is longer than
> PATH_MAX (as defined in limits.h of your os).

I think you're seeing what I saw back then. Then I submitted this patch which actually does two things:

1. Responds APR_ENAMETOOLONG when trying to check for filepath longer than supported

2. On APR_ENAMETOOLONG responses, instead of FORBIDDEN, result in APR_NOFILE which I believe resulted in some 404 - NOT FOUND response after all
Comment 36 Giovanni Bechis 2020-01-29 22:27:22 UTC
Created attachment 36987 [details]
long filenames 404 patch

This diff (very similar to your patch and rebased to trunk) will return 404 asap.
Comment 37 Julien Mrz 2020-04-09 09:31:51 UTC
Hi,

Do you have any update on it please ?


I'm facing an issue that seems to be related to this bug.

I've found in errorlog files that GoogleAdsBot sometimes requests urls using "%3F" instead of "?" for query parameters.
And when the string length of query parameters are >=255 chars, it results in "403 Forbidden".
It is very critical cause it can impact Adwords campaigns.

You can reproduce it with a standard installation of Apache2:
http://localhost/%3Ftest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255charte


Also tried on other websites, like:

- "%3F" followed by 255char: https://apache.org/%3Ftest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255charte
=> 403 Forbidden


- "%3F" followed by 254char: https://apache.org/%3Ftest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chartest254chart
=> 404 not found (normal behavior ?)

- "?" followed by 255char:
https://apache.org/?test255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255chartest255charte
=> works properly


I've also tried to use url rewriting to make a full redirect of any requests, and I got the same results: works until 254 chars, after it's Forbidden.

It seems that Apache2 doesn't evaluate config or htaccess files when we got the %3F +255char.
Comment 38 Giovanni Bechis 2020-04-10 08:50:34 UTC
I opened a bz in apr: https://bz.apache.org/bugzilla/show_bug.cgi?id=64170
waiting for somebody to commit the apr patch, then I can commit the httpd piece of the diff.
Comment 39 Giovanni Bechis 2020-04-10 11:00:43 UTC
Created attachment 37165 [details]
return 404 on too long filenames

fixed comment and add correct log error number
Comment 40 Giovanni Bechis 2020-04-10 11:09:18 UTC
Created attachment 37166 [details]
return 404 on long filenames

stat(2) return ENAMETOOLONG if filename is longer than MAX_PATH