On Mon, Nov 5, 2012 at 8:12 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Mon, Nov 5, 2012 at 8:07 AM, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Mon, Nov 5, 2012 at 8:01 AM, Lieven Govaerts <lgo_at_mobsol.be> wrote:
>>> On Mon, Nov 5, 2012 at 12:02 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>>>> On Nov 5, 2012, at 3:11 AM, Branko Čibej <brane_at_wandisco.com> 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.
>>>>> -- Brane
>>>> I thought that Serf already issues HEAD requests? Not sure about Neon.
>>> No it doesn't, serf only sends the requests provided by svn. (except
>>> when setting up an ssl tunnel, but that's not relevant here).
>> Are you talking about trunk specifically? When 1.7 was released, a
>> checkout/update done with a Serf client would issue a series of HEAD
>> and PROPFIND requests to the server. I think the changes that
>> cmpilato made to include the properties in the REPORT response removed
>> this on trunk, but I thought it was still true with 1.7.
> Hmm, I do not see this with current 1.7 client so maybe that was all
> changed before we released 1.7. I do see some mailing list threads
> that referenced it but maybe we were able to remove all those requests
> from the code.
> I recall this came up when I was raising the issue about the number of
> requests that Serf makes to the server so it is possible someone
> removed them.
Yep, this is the issue that removed the HEAD requests from Serf:
Anyway, my only point was that our server was already responding to
HEAD requests. Perhaps the response did not conform to the spec but
it was handling the requests already.
Received on 2012-11-05 14:28:49 CET