You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Paul J. Reder" <re...@remulak.net> on 2009/01/08 23:43:13 UTC

Question about response validity.

In server/core.c: ap_core_translate, the function apr_filepath_merge is called two
different times. Most of the errors from apr_filepath_merge relate to resulting
local path values that fall outside the valid server path and make sense to return a
403.

There is one case here that is not so clear though. Inside apr_filepath_merge, you
can also exceed the local system's PATH_MAX and the function returns
APR_ENAMETOOLONG.

This results in a 403 being returned for a case where we refused to process the
request because the resulting local path name exceeded the PATH_MAX value.

Should this return 414 when it gets APR_ENAMETOOLONG or is it valid to return 403?

-- 
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein


Re: Question about response validity.

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Paul J. Reder wrote:
> In server/core.c: ap_core_translate, the function apr_filepath_merge is
> called two
> different times. Most of the errors from apr_filepath_merge relate to
> resulting
> local path values that fall outside the valid server path and make sense
> to return a
> 403.
> 
> There is one case here that is not so clear though. Inside
> apr_filepath_merge, you
> can also exceed the local system's PATH_MAX and the function returns
> APR_ENAMETOOLONG.
> 
> This results in a 403 being returned for a case where we refused to
> process the
> request because the resulting local path name exceeded the PATH_MAX value.
> 
> Should this return 414 when it gets APR_ENAMETOOLONG or is it valid to
> return 403?

We've treated this as an 'oh - I can't find that resource' because, well,
it's not possible.  You don't want things like 414's for GET in terms of
establishing too many fingerprints.  But in DAV, a 414 might make perfect
sense (as a PUT).