Posts Tagged ‘development’

The unwritten rules of open source support

Sunday, July 13th, 2008

What’s extraordinary about the open source community is that this level of support happens all the time, every day, without charge, in hundreds, thousands of projects out there. People that can get to the bottom of a problem and fix it at the source, not just provide a workaround, are directly reachable and motivated to see their software work as well as possible. They’re not hidden away from the public behind a large corporation, unreachable with layers of clueless support script readers stuffed between you and them. Here are some rules for getting open source support directly from the projects:

  • Before asking anybody, do your homework. Use Google, read the project FAQ, make some attempt to learn the basics without pestering people with questions they’ve already answered hundreds of times. Nine times out of ten, your problem has already been encountered and somebody has figured out a workaround.
  • Limit the scope of your question to the fundamental problem. Get to the point. I’m obviously guilty of being tremendously long-winded at times, but unless your question is right at the top and asked directly, you’ll probably get ignored. Developers are busy, they don’t want to read a novel, but they’re usually happy to answer a question.
  • Provide supporting details after asking your question. Many programs will create a log with lots of information that can help somebody diagnose your problem. Find what looks relevant in the logs. Specify what version of operating system, distribution, application, etc. Specify what you were trying to do, what you expected, and what really happened. But provide this stuff after asking your initial question–people aren’t going to wade through a long email to find your question.
  • Contribute something. The easiest way you can contribute is by answering other people’s questions. The whole thing works because people help each other, and this help goes both ways. If you always ask questions and never answer anybody else’s, or provide any other sort of contribution, you’ll eventually start getting ignored.
  • Always, always, be positive, respectful, and polite when asking your questions. Developers have a lot invested in their project, and insulting it won’t gain you any favors. Developers are under no obligation to help you either–you haven’t paid for it. Common courtesy is valuable. Complements are welcome.
  • Be patient. Sometimes the person who has the answer to your question is away from the computer. Usually you’ll get your problem solved quicker than you would calling some tech support line, but there are times it’s going to take a while. If you don’t get any response in a reasonable period of time (judged by how active the list or forum is, reasonable could be a couple hours or a couple days), there are several likely reasons: You haven’t been specific enough in your question; you’re in the wrong forum (e.g. users when it’s a developer question); nobody else is trying to do what you’re doing (in which case you may need to hire someone with the right skills); the project is dead (it happens sometimes–find another one); or the developers are swamped (give them more time, or come up with a new scenario that sheds light on your problem in a different way).

That list describes how we get open source support at Freelock. Aside from a couple unsupported hardware devices, or issues with proprietary programs, we have yet to get stumped, in over 6 years of extremely heavy Linux and open source use. We’ve never paid a dime for this support, though we have provided help to many others in return.

REST, PHP, PUT, and WebDAV on Apache

Thursday, November 8th, 2007

We’re doing a fair amount of AJAX development these days, and ran into a problem with the REST convention. Thought I’d put my notes here in case somebody else runs into this.

REST, short for “Representational State Transfer” is a new-ish approach to managing state in a web application. With PHP, you typically manage state using its session features, which pass a cookie back and forth from the browser. Then the server needs to store values for each browser session, mirroring in some fashion the data in the browser with a cache on the server. This breaks down in a couple cases:

  1. You want to have multiple browser windows open into the same application
  2. Your application runs on a cluster of servers, and sessions cannot be safely/quickly retrieved (extremely high traffic sites)

REST is simply a set of guidelines for keeping all state in the browser, and passing all the necessary parameters the server needs to handle a request with every single request. And the REST architects are making use of the full HTTP specification, rather than just the parts that are in widespread use.

The vast majority of web sites make use of only two HTTP methods: GET, and POST. But there are quite a few others that are defined in the original specification, particularly PUT and DELETE that the REST practitioners rely on. It adds a couple useful verbs to the language that otherwise add more parameters to your simple POST.

The PHP language handles GET and POST very nicely, giving the programmer an array of variables passed by the browser. It can handle PUT and DELETE as well, but you have to access the body of these requests using a raw input stream. That much is fine. The problem I ran into when deploying an application that relies on PUT was that my PHP application never received the request. It did on my development machine, but when I moved it to an internal production machine, all the PUT requests were getting a “403 Unauthorized” error back from the server. Why would this work on one machine but not another?

It turns out to be a conflict with WebDAV. WebDAV is an extension of the HTTP protocol, which also uses PUT and DELETE, and adds a few others like OPTIONS, MKCOL, and more. We use WebDAV instead of FTP to allow our clients to copy files up to our servers–we can lock them into particular directories, and generally secure the server much better than we can with FTP.

However, apparently WebDAV intercepts ALL PUT requests to the server, even if it’s for a different virtual host. A bug in the mod_dav module, or mod_dav_fs? Don’t know. What’s strange is that Subversion, which runs as a Dav handler, does not conflict with our use of PUT–only regular Dav.

So for those running into this, what we found is that as long as you don’t have “Dav On” anywhere on that Apache server, PUT requests make it to the PHP handler just fine. Subversion can be enabled on particular servers or subdirectories, and then it becomes the PUT handler for those areas. The Dav modules can be loaded with no conflict. But as soon as you turn Dav On on any virtual host on the entire server, your PHP script will no longer get the request.