BITS problem solved

The server does not support the necessary HTTP protocol. Background Intelligent Transfer Service (BITS) requires that the server support the Range protocol header.

The latest application that I've worked on is a C# WinForms application that incorporates the Microsoft Updater Application Block to handle automatic updates. For Java developers, this is basically the equivalent of Java Web Start. Under the covers, the Updater Application Block uses BITS (Background Intelligent Transfer System) technology; the same technology that's running when you install a security patch from Microsoft. We encountered the above error with a single client site and it took an incredible amount of time to figure it out, and there was only a smattering of clues published on the web.

The error message may lead you to believe that the problem stems from a misconfiguration on our server. The following is a snippet from BITS documentation:

HTTP Requirements for BITS Downloads

BITS supports HTTP and HTTPS downloads and uploads and requires that the server supports the HTTP/1.1 protocol. For downloads, the HTTP server's Head method must return the file size and its Get method must support the Content-Range and Content-Length headers. As a result, BITS only transfers static file content and generates an error if you try to transfer dynamic content, unless the ASP, ISAPI, or CGI script supports the Content-Range and Content-Length headers.

BITS can use an HTTP/1.0 server as long as it meets the Head and Get method requirements.

To support downloading ranges of a file, the server must support the following requirements:

• Allow MIME headers to include the standard Content-Range and Content-Type headers, plus a maximum of 180 bytes of other headers.
• Allow a maximum of two CR/LFs between the HTTP headers and the first boundary string.

But the actual cause in this case was our client's firewall configuration. The firewall (SonicWall pro 5060) was interfering with the response from our server. The solution: our client opened our IP range on their CFS Exclusion List, Gateway AV Exclusion List, IPS Exclusion List, and Anti-Spyware Exclusion List.

Hope this helps someone else out there!

Lessons in SOA

Although I agree with the comments of George Carey about this article, I wanted to add a little personal experience to the underlying theme of the article that a SOA needs to be based on a loosely coupled abstraction layer. This is absolutely critical. Why? Because services can easily turn into a maintenance headache that is, "write once, maintain forever."

Coming from EJB/JSP-land, it's not initially apparent that point-to-point services are bad. Both Microsoft and Sun are selling how easy it is to produce and consume web services. But it becomes obvious over time that you're actually writing a public API rather than remote procedure calls. This is a significant shift in thinking and practice and shouldn't be underestimated. Under the basic constraints of API development, service signatures cannot change and contracts can't be broken. This can lead to versions of methods like getDocument(int) and then getDocument2(int, boolean), etc. Then in the future when a bug is found, you may end up maintaining getDocument() and getDocument2(). Of course we strive for proper encapsulation, but sometimes even good encapsulation cannot prevent the possibility of breaking a contract. So then you may even wind up maintaining different versions of compositions that basically perform the same task. Or, in the unlikely event that a database primary key changes, it may reverberate all the way through the system unavoidably breaking a contract. And even in a system with relatively few web services, this amount of maintenance can quickly become unacceptable.

My point is that in order to be successful with a SOA, you probably need to put even more work up front in design and more forethought in policies such as managing deprecation. And I understand that implementing a SOA is different than implementing a few web services. But as this article points out, this fundamental understanding needs to get to the core of an organization before the "if you build it, they will come" mentality.