On Aug 22, 2008, at 11:59, Brad Stiles wrote:
> Ryan Schmidt wrote:
>
>>>> My first guess would be that you have a proxy/router in the way
>>>> that
>>>> doesn't handle/rejects the subversion http methods for incoming
>>>> requests.
>
>>> machine. Is there something about the Subversion one that might be
>>> different? If so, what do I look for?
>
>> The issue is that a Subversion client with the neon library uses HTTP
>> methods other than the usual GET and POST (specifically, PROPFIND,
>> REPORT, MERGE) which many proxies or possibly routers don't know
>> about.
>
>> When browsing a repository in a web browser, only GET requests are
>> used which all proxies should understand.
>
> OK, if my questions reveal a misunderstanding of what you're
> telling me, I apologize.
>
> If one repo works, but another doesn't, using the same "svn ls"
> command, can that still be a problem with the proxy? That's an
> honest question, because I just don't know. If the answer is
> "Yes", and the reason is because of different dav modules, I'll see
> if I can figure out how to change it. If there are other reasons,
> I'd like to know those as well.
>
> It appears to me that, using the same client, svn.exe 1.4.6, on the
> same machine on the same network, invocation of "svn ls" against
> one Subversion repository yields a listing of the directory I've
> specified, but the other Subversion repository yields an error
> message, but only from the outside of my network. From inside, it
> works fine.
I understood that from inside your network, you can access your
repository that is inside your network, and access the official
Subversion repository which is outside your network, but from outside
your network you cannot access your own repository which is inside
your network. Thus, my only guess is that you have some kind of proxy
or other similar type of software restricting (perhaps
unintentionally) the types of HTTP methods allowed on incoming, but
not outgoing, traffic.
>> With Subversion 1.5, there's a new HTTP library you can use instead
>> of neon, called serf. Serf uses normal GET requests as well, as I
>> understand it, so switching from neon to serf could make the problem
>> go away. I understand the performance characteristics of neon and
>> serf differ slightly. Give it a try.
>
> I was unable to determine from documentation whether the
> installation I have is using neon or serf, so I will look at that
> when I get home, if I can figure it out. :) Which one is the
> http://svn.collab.net/repos/svn/ using, just for comparison? If
> it's the same one I'm using, what other explanations might be out
> there?
Not applicable: serf and neon are client-side, not server-side,
libraries. Type "svn --version" to discover which of these libraries
is available in your client.
>> Another option is to switch from HTTP to HTTPS. Because HTTPS is
>> encrypted, a proxy can't look inside the packets and can't care what
>> type of HTTP method is being used.
>
> I originally had it as HTTPS, but switched it for some reason I
> can't remember now. I'll try it again and see what happens.
HTTPS of course trades speed for security, and HTTP is already slower
than SVN-protocol access. So you'll have to evaluate whether the
speed hit of HTTPS is acceptable.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-22 19:15:41 CEST