On Mon, Nov 5, 2012 at 1:15 PM, Ivan Zhakov <i...@visualsvn.com> wrote: > On Mon, Nov 5, 2012 at 12:11 PM, Branko Čibej <br...@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. >> > I believe we use chunked responses and I assume they do not require > Content-Length header. >
Not anymore. Serf uses chunked encoding for requests if the content length of the request body isn't known up front. Svn explicitly sets the content length for requests when it is in HTTP/1.0 mode, which is the default for a new connection. (see the call to serf_bucket_request_set_CL in util.c:678) So the first request on a connection will always have the content length set: OPTIONS /kerbsvn/repos HTTP/1.1 Host: lgo-ubuntu.local User-Agent: SVN/1.8.0-dev serf/2.0.0 Content-Type: text/xml Connection: keep-alive DAV: http://subversion.tigris.org/xmlns/dav/svn/depth DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops Content-Length: 131 <?xml version="1.0" encoding="utf-8"?><D:options xmlns:D="DAV:"><D:activity-collection-set></D:activity-collection-set></D:options> > -- > Ivan Zhakov Lieven
