On Aug 22, 2008, at 09:32, Brad Stiles wrote:
>>> Another culprit could be interference from some tool on my
>>> employer's
>>> network. However, I can connect to "The Subversion Repository. No,
>>> really, *the* Subversion Repository," as well as a fair number of
>>> other Subversion repositories, from my work machine just fine.
>>
>> 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.
>
> That was my first thought as well, and I'll look at it again, but I
> can browse the subversion repository at http://svn.collab.net/repos/
> svn/, along with a number of others, just fine from my work
> machine. Is there something about the Subversion one that might be
> different? If so, what do I look for?
There shouldn't be anything different there...
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.
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.
http://subversion.tigris.org/svn_1.5_releasenotes.html#dav-modules
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.
---------------------------------------------------------------------
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 17:41:04 CEST