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

Re: [PATCH] HTTPv2 allow client to control transaction name in protocol

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 01 Mar 2011 13:56:43 -0500

On 03/01/2011 01:12 PM, Philip Martin wrote:
> "C. Michael Pilato" <cmpilato_at_collab.net> writes:
>> Just a thought: Have you considered expanding the scope of the private
>> resource space rather than using the magic prefix hack? You could add
>> ".../!svn/vtxn/UUID" and ".../!svn/vtxr/UUID/..." to be alternate ways to
>> address transactions and transaction roots (the "v" there being a shortcut
>> for "virtual"). This is *effectively* the same approach as yours -- there's
>> a different prefix here. But the prefix is a clearly defined piece of the
>> protocol, not just some magic bit buried in mod_dav_svn's codebase.
> I'll have a think about that. One aim is that the proxy can be as dumb
> as possible about the Subversion protocol, so that it doesn't have to
> rewrite all commit requests. If the client doesn't send the vtxn/vtxr
> URLs the proxy has to do more work.
> Another thing about exposing the transaction name in the protocol is
> that it is much more predictable than a UUID. Temporary files with
> predictable names can be a security issue, are predictable transaction
> names a security issue?

I want to say that we've had this discussion on-list before, but I might be
remembering something else. I'll see if I can find any prior chatter about

If there's reason to believe that the current approach is dangerous, then by
all means let's dispose of it, fall back to client-provided transaction
aliases, and move along! I don't have a particularly strong opinion on the
matter save for one: don't make the protocol unnecessarily complex!
Necessary complexity? Now that's a different matter altogether.

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2011-03-01 19:57: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.