[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: Bert Huijben <bert_at_qqmail.nl>
Date: Thu, 7 Mar 2013 18:21:41 +0100

> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> Sent: donderdag 7 maart 2013 17:32
> To: Bert Huijben
> Cc: 'Gavin Baumanis'; 'jinfroster'; dev_at_subversion.apache.org
> Subject: Re: [PATCH] implement keywords substitution in mod_dav_svn
> On 03/07/2013 11:27 AM, Bert Huijben wrote:
> >> Yeah, I *think* using the "is_svn_client" flag is acceptable. I can't
> >> remember now how much weight we attributed to that flag (which is set
> >> based on a grep of the User-Agent string). The downside here is that
> >> if there happens to be a Subversion client that doesn't report itself
> >> as such in this way, it will presumably run into the same sorts of
> >> issues we've already discussed. But I know of no such client, and
> >> maybe we as a community are willing to say, "Look, if you are to be a
> >> well-behaved Subversion client, you've gotta slap those four characters
> >> "SVN/" in your User-Agent header value.
> >
> > What about proxy servers?
> >
> > There used to be privacy features in several proxies that suppressed the
> > user agent. (Not sure if they still use that trick).
> 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.

Another possible issue: What about standard DAV clients?

Should these obtain the keywords collapsed or expanded.

Received on 2013-03-07 18:22:22 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.