[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Content-Length in HEAD responses (was: Re: Authz on Collection of Repositories)

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 8 Nov 2012 18:42:33 +0200

Thomas ├ůkesson wrote on Thu, Nov 08, 2012 at 15:15:03 +0100:
>
> On 5 nov 2012, at 09:11, Branko ─îibej wrote:
>
> > On 05.11.2012 00:21, Thomas ├ůkesson wrote:
> >> I did some tests with curl --head just as a sanity check. It seems to be a good choice for access control. I primarily wanted to see that HEAD requests were not allowed in situations where GET is not (e.g. when user has access in directories below).
> >>
> >> The HEAD requests I performed (minimal curl command) did not cause the server to provide Content-Length when returning "200 OK".
> >
> > Which is precisely what I was talking about in my other post. Such HEAD
> > responses are invalid. If we implement HEAD, we have to do it correctly.
>
> Right, I was just confirming that.
>
> I think this is approaching off-topic for this thread. The server
> (mod_dav_svn) currently does respond to HEAD requests without
> Content-Length, which appears to be invalid. Perhaps a separate
> issue/thread should discuss whether the HEAD response should be
> changed to conform with the specification.
>

We could also add Content-Length if it's not required but cheap to
compute. (svn_fs_file_length())

> On-topic, looking at the HTTP RFC, the HEAD request makes a lot of
> sense for access control purposes and that gives the server a chance
> to optimize the response even if, worst case, only the response
> bandwidth would be gained.
>
> /Thomas ├ů.
>
Received on 2012-11-08 17:43:14 CET

This is an archived mail posted to the Subversion Dev mailing list.