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

Re: [PATCH] implement keywords substitution in mod_dav_svn

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 7 Mar 2013 13:55:15 -0500

On 03/07/2013 12:21 PM, Bert Huijben wrote:
>> Then those proxy servers are already interfering with existing clients,
>> and preventing those clients from reporting capabilities, from storing
>> and fetch file lock metadata correctly, etc.
> I think we use different headers for the user agent and the capabilities
> and most other things.
> Proxies suppressing all non-default headers would have problems, but the
> user agent is sometimes an easy tweak to reduce the attack surface.

What I meant was that mod_dav_svn only bothers to parse a capabilities
header at all if the User-Agent string has "SVN/". If a proxy is stripping
User-Agent out, then I daresay that client is mergeinfo-disabled as a result
of this.

> Another possible issue: What about standard DAV clients?
> Should these obtain the keywords collapsed or expanded.

Ah! Now that's the rub! (Good catch, Bert.) We do *not* want a standard
DAV client GETting a resource with keywords expanded, tweaking it, and then
PUTting it back into the repository with expanded keywords.[1]

So it would seem that we would not want this behavior to be the default for
a GET request, regardless of the client requesting it. We could make it an
option toggleable via the query string portion of the URL -- even
automatically add that flag in the URLs presented by a GET of the containing
directory. But no, a standard GET request against the public URL should not
expand keywords.

-- C-Mike

[1] What happens if such a client screws up our "repository normal
    format" -- expanding keywords or futzing with newlines -- when
    PUTting a new version today?

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2013-03-07 19:55:49 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.