You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2008/06/12 03:51:43 UTC
DO NOT REPLY [Bug 45187] New: Long File name requests gives
FORBIDDEN response
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
Summary: Long File name requests gives FORBIDDEN response
Product: Apache httpd-2
Version: 2.2.4
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: critical
Priority: P1
Component: Core
AssignedTo: bugs@httpd.apache.org
ReportedBy: romangarciam@gmail.com
Created an attachment (id=22112)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=22112)
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 45187] Long File name requests gives FORBIDDEN response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
andre.tannus@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andre.tannus@gmail.com
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #14 from maca <ma...@gmail.com> 2009-03-12 08:15:14 PST ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 45187] Long File name requests gives FORBIDDEN response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
andre.tannus@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #18 from andre.tannus@gmail.com ---
What is the latest news on this? Will it be fixed?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
DanielFird <Da...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |www.longpathtool.com
--- Comment #15 from DanielFird <Da...@gmail.com> 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
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 45187] Long File name requests gives FORBIDDEN response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
Ryszard Łach <ry...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rylach@gmail.com
--- Comment #17 from Ryszard Łach <ry...@gmail.com> ---
I've just checked in apache 2.4.6 - the bug is applicable too.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
André Malo <nd...@perlig.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
URL|www.longpathtool.com |
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 45187] Long File name requests gives FORBIDDEN response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #16 from Ryszard Łach <ry...@gmail.com> ---
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 ?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 45187] Long File name requests gives FORBIDDEN response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #20 from Hiep Pham <ph...@gmail.com> ---
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?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 45187] Long File name requests gives FORBIDDEN response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #23 from Roman Garcia <ro...@gmail.com> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 45187] Long File name requests gives FORBIDDEN response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
Eric Covener <co...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #19 from Eric Covener <co...@gmail.com> ---
(needinfo means info is needed from the originator)
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #12 from mark <ma...@node.to> 2008-09-24 08:38:32 PST ---
FYI I encounter this exact problem with mod_python as well.
Apparently mod_python does not bypass the directory walk.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 45187] Long File name requests gives FORBIDDEN response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #24 from Hiep Pham <ph...@gmail.com> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 45187] Long File name requests gives FORBIDDEN response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #22 from Hiep Pham <ph...@gmail.com> ---
(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! ;)
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #13 from Nick Kew <ni...@webthing.com> 2008-12-31 11:54:04 PST ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 45187] Long File name requests gives FORBIDDEN response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
Anton Voloshin <as...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ashutosh108@gmail.com
--- Comment #21 from Anton Voloshin <as...@gmail.com> ---
(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.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 45187] Long File name requests gives FORBIDDEN response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
Christophe JAILLET <ch...@wanadoo.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |PatchAvailable
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
Roman Garcia <ro...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |romangarciam@gmail.com
Severity|critical |major
Status|NEEDINFO |NEW
OS/Version|Windows XP |Linux
--- Comment #2 from Roman Garcia <ro...@gmail.com> 2008-06-12 07:32:24 PST ---
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
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #5 from Jeff Trawick <tr...@apache.org> 2008-06-12 11:25:55 PST ---
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 ;) )
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #8 from Roman Garcia <ro...@gmail.com> 2008-06-12 13:50:57 PST ---
(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. ;)
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #10 from Ruediger Pluem <rp...@apache.org> 2008-06-12 14:26:20 PST ---
(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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #11 from Roman Garcia <ro...@gmail.com> 2008-06-12 15:51:27 PST ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #3 from Jeff Trawick <tr...@apache.org> 2008-06-12 08:16:39 PST ---
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
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #7 from Will Rowe <wr...@apache.org> 2008-06-12 12:44:02 PST ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #4 from Roman Garcia <ro...@gmail.com> 2008-06-12 09:05:11 PST ---
(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
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #9 from Jeff Trawick <tr...@apache.org> 2008-06-12 14:09:27 PST ---
>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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
--- Comment #6 from Roman Garcia <ro...@gmail.com> 2008-06-12 12:03:29 PST ---
(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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 45187] Long File name requests gives FORBIDDEN
response
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45187
Nick Kew <ni...@webthing.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #1 from Nick Kew <ni...@webthing.com> 2008-06-12 03:09:08 PST ---
You've marked this Windows XP, but your patch applies to Unix code. Please
clarify.
Also, calling it 'critical' seems way OTT.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org