You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Alexander Kitaev <Al...@svnkit.com> on 2008/03/14 18:17:50 UTC

Branch 1.5.x: mod_dav_svn restricts third-party Subversion clients too much.

Hello,

There is the following code in subversion/mod_dav_svn/repos.c:1643

     if (val && (ap_strstr_c(val, "SVN/") == val))
       {
         repos->is_svn_client = TRUE;

         /* Client capabilities are self-reported.  There is no
            guarantee the client actually has the capabilities it says
            it has, we just assume it is in the client's interests to
            report accurately.  Also, we only remember the capabilities
            the server cares about (even though the client may send
            more than that). */
         ....
       }

SVNKit honestly sends "SVNKit ..." User-Agent header and as a result 
capabilities reported by SVNKit are ignored by mod_dav_svn. Could the 
condition above be changed to:

     if (val && (ap_strstr_c(val, "SVN") == val))

So far we have to use SVN/Kit for User-Agent HTTP header value.
Thanks!

-- 
Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Branch 1.5.x: mod_dav_svn restricts third-party Subversion clients too much.

Posted by David Glasser <gl...@davidglasser.net>.
On Fri, Mar 14, 2008 at 12:30 PM, C. Michael Pilato <cm...@collab.net> wrote:
> Karl Fogel wrote:
>  > Alexander Kitaev <Al...@svnkit.com> writes:
>  >> There is the following code in subversion/mod_dav_svn/repos.c:1643
>  >>
>  >>     if (val && (ap_strstr_c(val, "SVN/") == val))
>  >>       {
>  >>         repos->is_svn_client = TRUE;
>  >>
>  >>         /* Client capabilities are self-reported.  There is no
>  >>            guarantee the client actually has the capabilities it says
>  >>            it has, we just assume it is in the client's interests to
>  >>            report accurately.  Also, we only remember the capabilities
>  >>            the server cares about (even though the client may send
>  >>            more than that). */
>  >>         ....
>  >>       }
>  >>
>  >> SVNKit honestly sends "SVNKit ..." User-Agent header and as a result
>  >> capabilities reported by SVNKit are ignored by mod_dav_svn. Could the
>  >> condition above be changed to:
>  >>
>  >>     if (val && (ap_strstr_c(val, "SVN") == val))
>  >>
>  >> So far we have to use SVN/Kit for User-Agent HTTP header value.
>  >> Thanks!
>  >
>  > Hmmm, thanks for pointing this out.
>  >
>  > Your suggestion seems reasonable to me.  It's pretty likely that
>  > anything starting with "SVN" is SVN-related, and wants to be treated as
>  > an SVN client.  But I'm not well-versed in the relevant standards here;
>  > does anyone know more?  (Let's give it a day or two, since the change is
>  > trivial and easy to backport to the 1.5.x line before rc1 comes out.)
>
>  -0.  Why doesn't SVNKit use:
>
>      SVN/x.y.z SVNKit/a.b.c
>
>  which would roughly translate as "This is a Subversion client compatible
>  with Subversion x.y.z and using SVNKit a.b.c as the implementation."

Something like that sounds good.  I think we should make this format
be supported by the new svn_ra_get_client_string thing too.

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Branch 1.5.x: mod_dav_svn restricts third-party Subversion clients too much.

Posted by Alexander Kitaev <Al...@svnkit.com>.
> -0.  Why doesn't SVNKit use:
 >
 >     SVN/x.y.z SVNKit/a.b.c
 >
 > which would roughly translate as "This is a Subversion client compatible
 > with Subversion x.y.z and using SVNKit a.b.c as the implementation."
Thanks Michael, good point and we'll do it the way you've suggested.

Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!

C. Michael Pilato wrote:
> Karl Fogel wrote:
>> Alexander Kitaev <Al...@svnkit.com> writes:
>>> There is the following code in subversion/mod_dav_svn/repos.c:1643
>>>
>>>     if (val && (ap_strstr_c(val, "SVN/") == val))
>>>       {
>>>         repos->is_svn_client = TRUE;
>>>
>>>         /* Client capabilities are self-reported.  There is no
>>>            guarantee the client actually has the capabilities it says
>>>            it has, we just assume it is in the client's interests to
>>>            report accurately.  Also, we only remember the capabilities
>>>            the server cares about (even though the client may send
>>>            more than that). */
>>>         ....
>>>       }
>>>
>>> SVNKit honestly sends "SVNKit ..." User-Agent header and as a result
>>> capabilities reported by SVNKit are ignored by mod_dav_svn. Could the
>>> condition above be changed to:
>>>
>>>     if (val && (ap_strstr_c(val, "SVN") == val))
>>>
>>> So far we have to use SVN/Kit for User-Agent HTTP header value.
>>> Thanks!
>>
>> Hmmm, thanks for pointing this out. 
>> Your suggestion seems reasonable to me.  It's pretty likely that
>> anything starting with "SVN" is SVN-related, and wants to be treated as
>> an SVN client.  But I'm not well-versed in the relevant standards here;
>> does anyone know more?  (Let's give it a day or two, since the change is
>> trivial and easy to backport to the 1.5.x line before rc1 comes out.)
> 
> -0.  Why doesn't SVNKit use:
> 
>     SVN/x.y.z SVNKit/a.b.c
> 
> which would roughly translate as "This is a Subversion client compatible 
> with Subversion x.y.z and using SVNKit a.b.c as the implementation."
> 
> ?
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Branch 1.5.x: mod_dav_svn restricts third-party Subversion clients too much.

Posted by Karl Fogel <kf...@red-bean.com>.
"C. Michael Pilato" <cm...@collab.net> writes:
> -0.  Why doesn't SVNKit use:
>
>     SVN/x.y.z SVNKit/a.b.c
>
> which would roughly translate as "This is a Subversion client
> compatible with Subversion x.y.z and using SVNKit a.b.c as the
> implementation."

That seems like a good idea.  First part says what semantics you have,
second part says what you actually are.  Both are useful, but for
different purposes.

-Karl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Branch 1.5.x: mod_dav_svn restricts third-party Subversion clients too much.

Posted by "C. Michael Pilato" <cm...@collab.net>.
Karl Fogel wrote:
> Alexander Kitaev <Al...@svnkit.com> writes:
>> There is the following code in subversion/mod_dav_svn/repos.c:1643
>>
>>     if (val && (ap_strstr_c(val, "SVN/") == val))
>>       {
>>         repos->is_svn_client = TRUE;
>>
>>         /* Client capabilities are self-reported.  There is no
>>            guarantee the client actually has the capabilities it says
>>            it has, we just assume it is in the client's interests to
>>            report accurately.  Also, we only remember the capabilities
>>            the server cares about (even though the client may send
>>            more than that). */
>>         ....
>>       }
>>
>> SVNKit honestly sends "SVNKit ..." User-Agent header and as a result
>> capabilities reported by SVNKit are ignored by mod_dav_svn. Could the
>> condition above be changed to:
>>
>>     if (val && (ap_strstr_c(val, "SVN") == val))
>>
>> So far we have to use SVN/Kit for User-Agent HTTP header value.
>> Thanks!
> 
> Hmmm, thanks for pointing this out.  
> 
> Your suggestion seems reasonable to me.  It's pretty likely that
> anything starting with "SVN" is SVN-related, and wants to be treated as
> an SVN client.  But I'm not well-versed in the relevant standards here;
> does anyone know more?  (Let's give it a day or two, since the change is
> trivial and easy to backport to the 1.5.x line before rc1 comes out.)

-0.  Why doesn't SVNKit use:

     SVN/x.y.z SVNKit/a.b.c

which would roughly translate as "This is a Subversion client compatible 
with Subversion x.y.z and using SVNKit a.b.c as the implementation."

?

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand


Re: Branch 1.5.x: mod_dav_svn restricts third-party Subversion clients too much.

Posted by Karl Fogel <kf...@red-bean.com>.
Alexander Kitaev <Al...@svnkit.com> writes:
> There is the following code in subversion/mod_dav_svn/repos.c:1643
>
>     if (val && (ap_strstr_c(val, "SVN/") == val))
>       {
>         repos->is_svn_client = TRUE;
>
>         /* Client capabilities are self-reported.  There is no
>            guarantee the client actually has the capabilities it says
>            it has, we just assume it is in the client's interests to
>            report accurately.  Also, we only remember the capabilities
>            the server cares about (even though the client may send
>            more than that). */
>         ....
>       }
>
> SVNKit honestly sends "SVNKit ..." User-Agent header and as a result
> capabilities reported by SVNKit are ignored by mod_dav_svn. Could the
> condition above be changed to:
>
>     if (val && (ap_strstr_c(val, "SVN") == val))
>
> So far we have to use SVN/Kit for User-Agent HTTP header value.
> Thanks!

Hmmm, thanks for pointing this out.  

Your suggestion seems reasonable to me.  It's pretty likely that
anything starting with "SVN" is SVN-related, and wants to be treated as
an SVN client.  But I'm not well-versed in the relevant standards here;
does anyone know more?  (Let's give it a day or two, since the change is
trivial and easy to backport to the 1.5.x line before rc1 comes out.)

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Branch 1.5.x: mod_dav_svn restricts third-party Subversion clients too much.

Posted by "C. Michael Pilato" <cm...@collab.net>.
Stefan Küng wrote:
> I remember we had this discussion when I first suggested the custom user 
> agent string. I had to change my patch to make sure that it had 'SVN/' 
> first and *then* the custom part.
> 
> As far as I understand, SVNKit just wants to use a custom string so it's 
> recognized as a different client. The indication of capabilities is done 
>  in the first part and (correct me if I'm wrong) has nothing to do with 
> the client library but only with the numbers after the 'SVN/'.

Actually, I believe that capabilities reporting is done in a different way 
altogether, not dependent on the User-Agent header, and definitely not 
dependent on version numbers.

> I doubt that mod_dav_svn would interpret the numbers/capabilities 
> differently if 'SVNKit/' instead of 'SVN/' was the first part of the 
> string.

The question isn't about how mod_dav_svn interprets numbers or capabilities. 
   It's all about having that "SVN/" in there.  mod_dav_svn treats clients 
which claim to be Subversion clients differently than other DAV clients. 
For example, Subversion clients are not permitted to lock non-existent 
files, but other DAV clients may (as required by Autoversioning). 
Subversion client lock comments are stored in the repository as provided by 
the client; non-Subversion client lock comments are stored as XML-ized 
blocks.  And there may be other differences I can't remember.

The point is, mod_dav_svn is explicitly looking for "SVN/" in the User-Agent 
header as a way of knowing that it is talking to a Subversion client. 
Trying to change that to look for "SVN/" and "SVNKit/" and "TortoiseSVN/" 
and ... well, that's ridiculous.  Hence, my suggestion that SVNKit keep the 
"SVN/" at the head of the User-Agent line and appent "SVNKit" elsewhere.  As 
a bonus, they could actually use the version number associated with "SVN/" 
as something meaningful (if only to humans) -- the version of Subversion 
with which they claim basic compatibility.

> So, SVNKit could use the same first part of the user-agent string as the 
> svn library, and then add the custom part at the end, as svn 1.5 does.
> 
> Or am I completely off the road here? (wouldn't be the first time :)

You've got two wheels on and two wheels off.  But that's okay -- from what 
I've seen with TortoiseSVN, you're a Range Rover!

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand


Re: Branch 1.5.x: mod_dav_svn restricts third-party Subversion clients too much.

Posted by Stefan Küng <to...@gmail.com>.
Karl Fogel wrote:
> Stefan Küng <to...@gmail.com> writes:
>> Subversion 1.5 allows clients to modify the user-agent string so it
>> can include the actual client used.
>>
>> Check the 'client_name' member of svn_client_ctx_t in the file
>> http://svn.collab.net/repos/svn/branches/1.5.x/subversion/include/svn_client.h
>>
>> I think SVNKit should do it the same way as Subversion 1.5.
> 
> Stefan,
> 
> His concern is the reverse: our *server* is checking for a particular
> user agent string prefix, and the question is what should SVNKit
> transmit in order to cause the right recognition by mod_dav_svn.

I remember we had this discussion when I first suggested the custom user 
agent string. I had to change my patch to make sure that it had 'SVN/' 
first and *then* the custom part.

As far as I understand, SVNKit just wants to use a custom string so it's 
recognized as a different client. The indication of capabilities is done 
  in the first part and (correct me if I'm wrong) has nothing to do with 
the client library but only with the numbers after the 'SVN/'.

I doubt that mod_dav_svn would interpret the numbers/capabilities 
differently if 'SVNKit/' instead of 'SVN/' was the first part of the string.

So, SVNKit could use the same first part of the user-agent string as the 
svn library, and then add the custom part at the end, as svn 1.5 does.


Or am I completely off the road here? (wouldn't be the first time :)

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net


Re: Branch 1.5.x: mod_dav_svn restricts third-party Subversion clients too much.

Posted by Karl Fogel <kf...@red-bean.com>.
Karl Fogel <kf...@red-bean.com> writes:
> Stefan Küng <to...@gmail.com> writes:
>> Subversion 1.5 allows clients to modify the user-agent string so it
>> can include the actual client used.
>>
>> Check the 'client_name' member of svn_client_ctx_t in the file
>> http://svn.collab.net/repos/svn/branches/1.5.x/subversion/include/svn_client.h
>>
>> I think SVNKit should do it the same way as Subversion 1.5.
>
> Stefan,
>
> His concern is the reverse: our *server* is checking for a particular
> user agent string prefix, and the question is what should SVNKit
> transmit in order to cause the right recognition by mod_dav_svn.

Erik Huelsmann pointed out to me in IRC that you understood this, and
you were just suggesting to the SVNKit folks that there is already a
precedent for solving it.  Sorry for misunderstanding you, and +1 on
using whatever mechanism we already came up with! :-)

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org


Re: Branch 1.5.x: mod_dav_svn restricts third-party Subversion clients too much.

Posted by Karl Fogel <kf...@red-bean.com>.
Stefan Küng <to...@gmail.com> writes:
> Subversion 1.5 allows clients to modify the user-agent string so it
> can include the actual client used.
>
> Check the 'client_name' member of svn_client_ctx_t in the file
> http://svn.collab.net/repos/svn/branches/1.5.x/subversion/include/svn_client.h
>
> I think SVNKit should do it the same way as Subversion 1.5.

Stefan,

His concern is the reverse: our *server* is checking for a particular
user agent string prefix, and the question is what should SVNKit
transmit in order to cause the right recognition by mod_dav_svn.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org


Re: Branch 1.5.x: mod_dav_svn restricts third-party Subversion clients too much.

Posted by Stefan Küng <to...@gmail.com>.
Alexander Kitaev wrote:
> Hello,
> 
> There is the following code in subversion/mod_dav_svn/repos.c:1643
> 
>     if (val && (ap_strstr_c(val, "SVN/") == val))
>       {
>         repos->is_svn_client = TRUE;
> 
>         /* Client capabilities are self-reported.  There is no
>            guarantee the client actually has the capabilities it says
>            it has, we just assume it is in the client's interests to
>            report accurately.  Also, we only remember the capabilities
>            the server cares about (even though the client may send
>            more than that). */
>         ....
>       }
> 
> SVNKit honestly sends "SVNKit ..." User-Agent header and as a result 
> capabilities reported by SVNKit are ignored by mod_dav_svn. Could the 
> condition above be changed to:
> 
>     if (val && (ap_strstr_c(val, "SVN") == val))
> 
> So far we have to use SVN/Kit for User-Agent HTTP header value.
> Thanks!

Subversion 1.5 allows clients to modify the user-agent string so it can 
include the actual client used.

Check the 'client_name' member of svn_client_ctx_t in the file 
http://svn.collab.net/repos/svn/branches/1.5.x/subversion/include/svn_client.h

I think SVNKit should do it the same way as Subversion 1.5.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net