Site Server Express - Understanding Posting Acceptor

Posting Acceptor Operation

The following section provides an overview of the components, functionality, and concepts that make up Posting Acceptor operation.

Posting Acceptor Components

Two sample pages are provided with the Posting Acceptor server add-on: one designed to accept multi-part/form-data method posts from Netscape Navigator, and one to provide the ActiveX Upload control for Microsoft Internet Explorer users. You can modify these pages to fit your needs.

The Active Server Pages (ASP) file (upload.asp) detects the type of incoming browser and routes the user to the appropriate sample page. If the user has a browser that supports ActiveX controls, he or she is routed to the page containing the ActiveX Upload control. If it is not yet installed, the user's system is automatically updated with the control. The following table describes the functions of the components, including sample pages, that make up Posting Acceptor.

Background Functions

The following section provides a summary of functions performed by Posting Acceptor and the concepts behind those functions. This includes authenticating content publishers, processing a content post after it is received, managing content reposting failure, and creating mapping modules.

Built as an ISAPI application, Posting Acceptor accepts HTTP-based "POST" requests that contain a TargetURL for the incoming content. Posting Acceptor then parses the URL to a base that matches a hosted site, which is determined by querying the configured mapping modules until one succeeds. The remainder of the URL is assumed to be subdirectories of the matched/hosted URL. The incoming files are then deposited into the appropriate directory selected by the module.

Posting Acceptor takes content posts from any client conforming to the rules outlined in the HTTP multi-part/form-data method (RFC 1867), including Netscape Navigator (with the use of a form on the server). Further posting options are also supported if the client code is Microsoft WebPost API based, for example, Web Publishing Wizard and any other applications using the ActiveX Upload control.

Authenticating Publishers

Authentication of publishers is handled by any mechanism that is exposed by Windows NT on the server that matches the authentication method supported by the client-side software; for example, Basic/NTLM/MSN/DPA (Distributed Password Authentication) or Microsoft Membership System.

Note Posting Acceptor specifically disallows anonymous connections.

IIS and PWS enumerate supported authentication methods and negotiate with the client to find a match. You can control who is allowed to post to a given site by establishing accounts for those users on the server. You can also control which directories those users can post to by applying access control lists (ACLs) to the various destination directories for that site. For more information about applying ACLs to a destination directory, see the Windows NT and Windows 95 user guides.

Your client's publishing software can authenticate against your Web server to upload their files using Microsoft Membership System or any other authentication mechanisms supported by Microsoft Internet Information Server (IIS), Peer Web Services, and Personal Web Server.

If you have installed a Security Certificate on your Web server, your publishers are able to upload their files securely via HTTPS (Hypertext Transfer Protocol Secure) assuming that the client supports SSL (Secure Sockets Layer).

Processing After Receiving Posts

If you want to perform additional processing after a post is received, Posting Acceptor can call a secondary post-processing URL with all the form data except the contents of the posted files uploaded from the client. In place of the content is a list of locations and sizes of the files posted to the server. You are able to edit the PostInfo file in order to specify the post-processing URL.

If a PostInfo file is not supplied, the option of specifying a post-processing URL is exposed in the WebPost API. You can also add it to the HTTP (uploadN.asp) sample page. The post-processing URL is specified as a part of the PostingURL after the PUBLISH keyword.

As part of the repost, the acceptor sends URL-encoded form fields of well known names, which list the locations where each of the uploaded files was saved. This form data is appended to any form data that already resides in the request. For each of the files uploaded and saved, the following will be passed on to the repost URL:

FileName=page 

FilePath=c:\test 

FileSize=32 

FileExtention=htm 

FileName=...

PostInfo File

The PostInfo file contains several definitions for the WebPost client, one of those definitions being the posting URL, which by default points to Posting Acceptor. The PostInfo file is used by the WebPost Publishing Wizard only. The WebPost API on the client's machine figures out where to post content by information it receives from the PostInfo file.

Repost Failures

In the case of repost failure, a warning message embedded inside the HTML repost is sent to the user. A repost failure is marked as a warning, not an error. A program that only checks for errors, such as WebPost, is not aware that the repost failed. If the repost succeeds, anything returned from the repost is sent back to the client. The acceptor then becomes transparent, meaning that it does not send anything back on its own. If no content is returned from the repost, the acceptor sends a warning message back to the client.

Mapping Modules

The mapping module is a self-registering server that creates the appropriate entry in the Posting Acceptor's mapping modules registry during registration.

Inside the registry, Posting Acceptor expects to find DWORD values, names of which are the Class IDs of mappers, and the values of which are either 1 (enable) or 0 (disable). For example, the entry for the Microsoft Content Replication System (CRS) mapping module looks like this:

{66BE7352-83A0-11D0-A317-00C04FD7CFC5}:REG_DWORD:0x1

The acceptor queries each of the installed mapping modules until one of them succeeds and a physical location is returned to the acceptor. If no mapping module succeeds, the acceptor defaults to querying IIS for the physical location of the given URL. If the default also fails, the acceptor returns an error message to the client.

Posting Acceptor can be configured with one or several mapping modules to route the incoming files to the desired location. When more than one mapping module is available, you can control where the user's content is routed depending on user permissions and setup specifications in the mapping modules.

Note Mapping module keys are located in HKLM\Software\Microsoft\WebPost\Acceptors\CPSHost\Mappers\