#7857 SF web server closes the connection

self-service
Chris Tsai
None
2014-06-09
2014-06-08
No

I came across a bug in the sourceforge web server, where it refuses connections from my application. I have a small text file on the project web page that contains version information. The application simply fetches that text file to see whether a new version is available. At some point, all users of my application started getting errors that they couldn't retrieve update information.

The problem seems universal across all of sourceforge, and is not limited to the project web space. For example, this will fail:

wget --user-agent Mozilla/5.0 https://sourceforge.net

I don't know what's so special about Mozilla/5.0 as user-agent, but it triggers the bug. It's probably the most compatible user-agent string out there for simple HTTP, and some network stacks use it as default. The network stack in this case is Qt's network module, which uses "Mozilla/5.0".

Discussion

  • Chris Tsai
    Chris Tsai
    2014-06-09

    • status: unread --> self-service
    • assigned_to: Chris Tsai
     
  • Chris Tsai
    Chris Tsai
    2014-06-09

    This is known and intentional. We specifically block that because of abuse that has come from that user-agent (being default also means that malicious behavior often uses that user-agent as well). You should set the user-agent to be something that includes your project name and/or URL so we know who to contact if we start to notice abusive behavior from your software.

    Regards,
    Chris Tsai, SourceForge.net Support

     
    • Thanks for the response.

      I think that what I'll be doing is to copy a user-agent string from a major browser. which will guarantee that I'll never get blocked again.

       
      • Chris Tsai
        Chris Tsai
        2014-06-09

        That's a bad idea. As I suggested earlier, you really should be identifying yourself correctly (ie., use a UA string that's specific to your software).

         
        • That would work too of course, but it wouldn't serve as a demonstration of how futile the attempt to filter generic and very commonly used user-agents is :-)

           
          • Chris Tsai
            Chris Tsai
            2014-06-09

            Ultimately, our suggestion is in your best interest and not just to be a pain.

            Unless we have an identifiable UA, if there's abusive traffic hitting your site, we may need to resort to just taking it offline. If we have an identifiable UA, we'll be able to reach out and work with you to resolve the issue instead.