3.1. Understanding the Basics of Remote Authoring
In this section, you learn some of the basic components that form the foundation of the remote-authoring features of SharePoint Designer. It's important to understand that remote authoring (or live editing) is not a SharePoint Designer-only feature. SharePoint Designer is mostly an intelligent consumer of the remote-authoring technologies provided by the client computer on which it's installed and the Web server computer where the remote Web site resides.
3.1.1. Client: the SharePoint Designer machine
From a user's perspective, SharePoint Designer is all you need on the client machine to be able to edit (or publish to) remote Web sites and SharePoint Web applications. However, SharePoint Designer relies on a number of other services offered by the operating system to successfully perform its operations. These services cumulatively become the client side of the remote-authoring features of SharePoint Designer.
3.1.1.1. Internet Explorer
SharePoint Designer relies on IE (WinINet.dll) for its HTTP settings, proxy server configuration, and authentication support. If you open SharePoint Designer, choose Tools 
Application Options, and then click the General tab, you find the Proxy Settings button. This button actually opens the Internet Properties dialog box, as shown in Figure 3.2, in the Connections tab and allows you to set settings for the proxy server to be used.
Also, SharePoint Designer respects the IE security zone settings for security and user authentication as well as advanced settings for HTTP 1.1 and passive FTP.
Figure 3.2. The Internet Properties dialog box
3.1.1.2. Web Client service
The Web Client service offered by the Windows XP, Windows Server 2003, and Windows Vista operating systems allows Web-based HTTP addresses (for example, http://webservername) to be accessed as Uniform Naming Convention (UNC) paths (\webservernamefoldername). This feature provides a mechanism to map network drives to Web-based addresses.
3.1.1.3. Web Folders
Web Folders offers the underlying infrastructure that allows you to open your remote Web sites in a Windows Explorer-like interface. If Web Folders is properly configured on your client machine and your Web server supports remote authoring, it can be used to manage the Web site content and add, remove, view, and copy files and folders to and from your remote Web site.
I discuss the Web Client service and Web Folders in more detail later in this chapter.
3.1.2. Web server: the site-hosting machine
The Web server (IIS for this discussion) is the machine that hosts the Web sites and Web applications.
While I previously discussed the components that enable remote authoring on a Web server, I must mention that in order to enable live editing of Web sites in SharePoint Designer, the Web server must support one of these technologies:
FTP
WebDAV
FPSE
SharePoint
3.1.3. Client-server communication protocols
HTTP is the base communication protocol that SharePoint Designer uses to converse with a Web server. All other application protocols that SharePoint Designer exploits — for example, FrontPage Remote Procedure Call (RPC), which is discussed later in this chapter — are HTTP-based.
HTTP protocol is not just limited in use for SharePoint Designer. It is, in fact, the standard communication protocol for interaction between a Web client (for example, a Web browser) and a Web server. When you type an address in a Web browser to view a Web site, the browser creates an HTTP request and sends it to the Web server for processing. When the processing is complete, the Web server sends an HTTP response back, which the browser interprets and then displays as a Web page. The HTTP request is usually composed of these parts:
A request line, such as GET /_vti_bin/author.dll HTTP/1.1, which requests the file author.dll from the /_vti_bin directory. Here, GET is the HTTP verb being used to indicate that the browser wants to retrieve the requested resource. Commonly used HTTP verbs are GET, HEAD, POST, OPTIONS, etc.
Headers, such as Accept-Language: en. These headers provide a way for a browser to tell the Web server about itself and the technologies that it supports.
An empty line
An optional message body. This is usually the place in the HTTP request where the FrontPage Remote Procedure Call (RPC) methods and SharePoint Simple Object Access Protocol (SOAP) messages are sent. FPSE (and SharePoint SOAP Web Services) reads this section to determine the action that needs to be performed for framing the HTTP response to the Web browser for the request.
Similar to the HTTP request, the HTTP response also has these sections:
Response line, such as HTTP/1.1 200 OK, which indicates the result of the processing done by the Web server for the HTTP request. If the processing fails for some reason, the response code (for example, 401, 500, etc.) indicates the type of failure.
Headers, such as Content-Length: 438. Like in the case of the HTTP request, the headers in the response allow the Web server to specify information about itself and the response that it just sent.
An empty line
A message body; this is the actual response that's parsed by the browser and displayed for a user's viewing. In the case of FPSE and SharePoint sites, this section might also contain information that SharePoint Designer can use for various purposes, such as displaying folder lists, rendering Web site content, working with Web parts, etc.
As discussed later in this chapter, FPSE (and SharePoint) sends a lot of optional information in the HTTP request body. This information usually contains a Web method (with parameters and values), which is executed on the Web server by FPSE (or SharePoint) to form an HTTP response that SharePoint Designer can utilize to perform its functions. Obviously, if the execution fails and the HTTP response indicates a failure, SharePoint Designer functionality relying on the response also fails.