Life after FPSE (Part 5)
We recently hosted a group of customers from a large hosting company here at Microsoft, and as the meeting was getting started everyone in the room was introducing themselves to the other attendees. As I was shaking hands with one of our visitors, I introduced myself by name and he had a brief moment of recognition, then he asked, "Wait a minute - are you the guy that's trying to drive a stake through the heart of the FrontPage Server Extensions?" I laughed and answered, "Well, I wouldn't put it that way, but yes - that's me." He ecstatically replied "Thank you!" and proceeded to give me a high five, then he continued the discussion by explaining how much he hated the FrontPage Server Extensions (FPSE).
This is a fun story for me to tell, and it more than adequately describes a lot of the sentiment that I've experienced from web hosting companies throughout the past decade. After the meeting had ended, one of my newer coworkers asked me where all the animosity for FPSE came from. I proceeded to recount several of the horror stories that I had seen with hosting companies over the past fourteen years that I've worked with FPSE - so I thought that I'd share a few of those miseries in a blog. (Because misery loves company...
FPSE Server-Specific Issues
I mentioned in an earlier blog that when Microsoft acquired Vermeer Technologies Inc. back in 1996, Microsoft did so in order to add FrontPage to the family of Office products.
 |
 |
| Vermeer FrontPage 1.0 |
Microsoft FrontPage 1.1 |
In 1996 the Internet was still new to most organizations, so there weren't a lot of people that knew the server-side of web hosting operations. I also mentioned in that blog that a couple of my coworkers and I used to spend our spare time searching the Internet and looking for servers that were using FPSE incorrectly, then we would call them and offer to help fix their web site's settings for free.
One of the big problems that I remember seeing was when customers couldn't figure out their security settings for FPSE, so they would configure their Unix web server to run as "root" or configure IIS to run as "administrator." Needless to say, this made their immediate security problems seem to go away, but it left their servers wide open to attack. Here's a couple of stories from that time period:
I vividly recall speaking with a customer that was running an early version of Apache or NCSA, and I asked him which user he was running his httpd process as. He asked how he would find that out, so I described using ps to get a list of running processes and their associated usernames (e.g. "ps -aux | grep 'httpd'") It turns out that he was running all httpd instances as root, so I explained that he should create a different user account and run all httpd instances as that user. He was quiet for a while, then he asked, "How do I create a user?" I asked if he could get his system administrator, and he was quiet again. After a short pause he said, "I am the system administrator." You can assume how the rest of that conversation progressed, but I can assure you that explaining how to add a user and to use chown to set his file permissions for every relevant file and directory was no picnic.
Things weren't any better when IIS came along - a lot of Windows NT administrators suddenly found themselves in charge of websites when they couldn't tell you what TCP/IP meant. (This was back in the days when most networks ran on NetBEUI and IPX/SPX.) This is a true story - I had a good friend named Luis that was talking a customer through a problem with FPSE and IIS 1.0 on Windows NT 3.51. More often than not customers weren't using NTFS, so they had no file security and their websites were wide open. My friend asked the customer, "Are you running FAT?" There was a long, awkward silence for a half a minute or so, then the customer responded, "I really don't see what my weight has to do with this." (To quote Nick Burns - Your Company Computer Guy, "I wish someone here knew about computers because that would have gotten a laugh.")
In the end, these kinds of problems weren't actually problems with FPSE - these problems were that FPSE made it easier for someone to do something malicious with these customers' servers. I think that stories like this were the beginning of the love/hate relationship that many hosting companies had with FPSE - hosting with FPSE meant that you could attract a lot of customers, but FPSE had a large learning curve that most hosting companies didn't want to be bothered with.
The other problem that drove web hosting companies crazy about FPSE was that it wanted to micro-mange your file security. Server administrators would spend hours tweaking the file permissions for their web site, but FPSE needed to set specific permissions in order to work correctly. The end result of this was not pretty, because FPSE would always overwrite any custom file permissions. (I think that this may have been the single-greatest source of FPSE aggravation for most hosting companies.)
FPSE Client/Server Issues
But the web authoring clients that communicated with FPSE didn't make things any better - sometimes they made things worse. Here's a perfect example: when some FPSE-enabled web authoring clients would attempt to communicate with a server, they would first issue an OPTIONS command to discover the authoring environment on the web server. This was actually a good idea in practice, but in this situation these web authoring clients were looking for a proprietary HTTP header named MS-Author-Via, which would inform the web authoring client which client-recognized protocols it could use; specifically FPSE or WebDAV. Unfortunately, there was a short period of time where IIS would return this header with incorrect values due to a memory fragmentation error that was later fixed, so we had to publish a knowledgebase article with a workaround for the problem. (The value for this header depends on the value of the FrontPageWeb metabase property, which was a leftover from IIS 4.0, but I don't think that anyone really cares about that level of detail except me.
But the MS-Author-Via header was only the first level where things could go wrong - the next request from FPSE-enabled clients was for a file named "_vti_inf.html" that FPSE would put in the root of the site. This file is very small, but it includes the following HTML comment that is especially important to an FPSE-enabled client:
<!-- FrontPage Configuration Information
FPVersion="5.0.2.6790"
FPShtmlScriptUrl="_vti_bin/shtml.dll/_vti_rpc"
FPAuthorScriptUrl="_vti_bin/_vti_aut/author.dll"
FPAdminScriptUrl="_vti_bin/_vti_adm/admin.dll"
-->
Here's how the "_vti_inf.html" is used: if an FPSE-enabled client can access this file and the information that it contains, then it will use the paths that are listed in the file to talk to FPSE through ISAPI; if the client it can't access the file, then it assumes down-level CGI functionality and makes a request for "_vti_bin/shtml.exe/_vti_rpc". In an attempt to alleviate this problem and to provide backwards-compatibility with FrontPage 1.0 (which couldn't use ISAPI), FPSE used to install an ISAPI filter named "fpexedll.dll" on IIS. This filter listened for inbound requests to the CGI-based FPSE paths and rewrote them to their corresponding ISAPI paths - this was great if "_vti_inf.html" was missing, and quite often this file was missing because people didn't know what it was doing in their web site and they deleted it.
But "fpexedll.dll" introduced it's own problems - at one point it had a memory leak so many hosting companies got used to removing it whenever they installed FPSE, and other hosting companies simply didn't like wasting resources on ISAPI filters that they didn't need so they would remove it as well. In either case, this DLL helped to give FPSE a bad name within the hosting community. But if the "fpexedll.dll" filter was missing and the client couldn't access "_vti_inf.html," then FPSE functionality would just fail - even if FPSE was installed correctly and all of the permissions were correct.
There are other issues with authentication for the "_vti_inf.html" file on a parent web when used with unique permissions on a child web that caused a score of other problems, but I won't go into that. :-(
Proprietary Versus Standards
Despite the problems that I mentioned earlier, FPSE was great in its day - at the time there was really nothing that compared with it. FPSE was more powerful than FTP, and WebDAV had yet to be created. But that being said, publishing over FPSE was made possible through a proprietary HTTP-based Remote Procedure Call protocol that Microsoft made available to the public. A handful of non-Microsoft clients took advantage of this protocol and developed their own publishing solutions, but primarily it was Microsoft clients that supported this protocol.
Skipping ahead a little over a decade, FTP is still quite often the publishing protocol of choice for many web authors and hosting companies, although WebDAV has been around now for just over ten years and continues to win mindshare. With that in mind, a large number of web authoring clients now support WebDAV natively, and most operating systems will allow you to connect to WebDAV-enabled websites as easily as you would connect to any other network resource. For example, Windows uses the WebDAV Redirector, Max OS X has WebDavFS, and most versions of Unix/Linux can use davfs2 or cadaver.
The best part about website publishing over FTP or WebDAV is the fact that both of these protocols are standards-based, instead of the proprietary RPC protocol that was used by FPSE. This has led to wider adoption across the industry for FTP and WebDAV, and the number of clients to choose from for each of these standards-based protocols continues to increase each year.
 |
When FPSE ceases to be supported later this year, there's a part of me that will probably be a little nostalgic about it. After all, FPSE has been around now since 1995, and it has had a great run for fifteen years. So even though I might be somewhat sad to see it go, I think we can all agree that it's time the Internet moved on.