On 02.11.2012 15:25, C. Michael Pilato wrote:
> On 11/02/2012 09:50 AM, Mark Phippard wrote:
>> On Fri, Nov 2, 2012 at 4:13 AM, Ivan Zhakov <i...@visualsvn.com> wrote:
>>> Looking forward for your review. Thanks!
>> + /* Build a Public Resource uri representing repository root. */
>> + uri = svn_urlpath__join(dav_svn__get_root_dir(r),
>> + svn_path_uri_encode(repos_name, pool), pool);
>> +
>> + /* Check if GET would work against this uri. */
>> + subreq = ap_sub_req_method_uri("GET", uri, r, r->output_filters);
>>
>> Just a drive-by, so if I am way-off just say so.
>>
>> I am assuming that since this is doing a GET, the server will have to
>> fully process it as if it would for a web browser making the same
>> request. So on a repository like the ASF or Wordpress where there are
>> a lot of top level folders then the server might have to do a fair
>> amount of work to process the request and return. I assume we do not
>> care about the content of the response, just the success or failure.
>>
>> So I am just wondering if there is a lighter weight HTTP request we
>> could do that would still trigger the authz check? Something like
>> OPTIONS or PROPFIND. Whatever would make sense and be quick to
>> process.
> I think HEAD[1] request would be the appropriate request here. (And I
> wonder, in retrospect, why we aren't using it for our regular in-repos
> path-based authz...)
>
> -- C-Mike
>
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4
If you read that section in the RFC carefully, it implies that there's
no guarantee that the server would have to perform less work for a HEAD
request compared to a GET; e.g., if the GET response would contain a
content-size header, and getting the size was expensive, HEAD would
still have to calculate it. All you really gain is response bandwidth.
-- Brane
