Subversion is an essential tool for programmers. It is a real pain if subversion is suddenly blocked because of a reconfiguration of a company firewall. This has actually happened to me two times at two different jobs now.

Subversion traffic is over http (port 80), but, as far as I understand, it is special in the sense that it makes use of the PROPFIND http request type, which is not part of ordinary web traffic.

To prove that indeed PROPFIND was being blocked by our firewall, I did the following:

  • svn command from inside the company works fine. For example:

    svn log http://svn.bigcat.unimaas.nl/pathvisio

  • The same svn commands from outside the company hangs indefinitely. I confirmed this on three different outside locations. (A collegue reported a timeout message that mentions PROPFIND)
  • Browsing to this page: http://svn.bigcat.unimaas.nl/pathvisio/ works fine from inside and outside.
  • To show that it's not somehow a subversion problem, you can get the same effect with curl. The following command works from inside, but hangs indefinitely from outside:

    curl http://svn.bigcat.unimaas.nl/pathvisio/ -H "Depth: 0" --request PROPFIND

  • An ordinary GET request works both inside and outside:

    curl http://svn.bigcat.unimaas.nl/pathvisio/

In both jobs, when I raised the issue with ICTS, their response was something like: "port 80 is open, we can't reproduce", and they just ignore my talk on http request types.

My questions are:

  • To be absolutely sure, is my method sufficient to prove that the problem is in blocking PROPFIND?
  • Do firewalls commonly block PROPFIND?
  • Can you give me suggestions how to explain this problem in the right language / terminology so that ICTS responds to it? I never administered a company firewall, I have no idea how that goes.
  • 2
    If something were blocking it, it would be a proxy server, not the firewall. Perhaps you'll have better luck if you ask about a proxy and/or filtering server. – EEAA Sep 22 '11 at 15:05
  • Good point. That's exactly what I mean by using the "right language" Please make that an answer :) – amarillion Sep 22 '11 at 15:12

I think your method is sufficient to indicate that the firewall seems to be blocking PROPFIND requests. And yes, it's not uncommon for firewalls to block HTTP methods that are rarely (or less commonly used). There's not really any special language you need to use to explain it to them, a good firewall administrator will already know that he's got these lesser used methods blocked.


Use a network capture software like Wireshark to see the traffic when using SVN and when using a web browser and compare the two captures. Use "Follow TCP stream" from the context menu of Wireshark to see the HTTP conversation.

  • This would show the PROPFIND leaving his computer, but not whether or not the command made it through the firewall/proxy. – EEAA Sep 22 '11 at 15:13
  • 1
    Based on his description of the requests "hanging", the firewall is probably discarding the request completely and never sending a response. So as @ErikA mentioned, he will see the outbound packet, but never see anything coming back. – Coding Gorilla Sep 22 '11 at 15:14
  • I know, but he will have something to show to the networking team. – Mircea Vutcovici Sep 22 '11 at 18:41
  • Do firewalls commonly block PROPFIND?

I am sure, no.

  • somebody disagree? cant believe – Korjavin Ivan Sep 22 '11 at 15:18
  • Your answer is a bit short. Care to elaborate? – amarillion Sep 22 '11 at 15:19
  • I disagree, I always filter my HTTP requests to only allow things like GET, POST, etc. Unless there's a specific requirement to allow the others. In security, least is best. – Coding Gorilla Sep 22 '11 at 19:51
  • so. always l7 filtering ? For what? You dislike PUT ? – Korjavin Ivan Sep 22 '11 at 20:32

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.