Decoded Methods

Last modified: March 23, 2010

Applies to: SharePoint Foundation 2010

The decoded sections in this reference do not show the code you actually see when you use a program such as Network Monitor, which allows examination of network traffic to and from the server at the packet level, capturing packets between FrontPage Server Extensions from Microsoft and a client application such as Microsoft Office FrontPage2003. This topic describes the code you observe in a packet-capturing program and the steps taken in this reference to make examples readable.

Note Note

Depending on the operating system and the program you use, you can filter packets either as HTTP or TCP packets. If you use TCP as the filter, you must inspect each TCP packet for the HTTP POST command. For instance, on UNIX systems, the HTTP protocol is always embedded in the TCP packet.

The first packet you capture is usually the HTTP POST. It is followed by a Keep-Alive packet. The last packet or set of packets to be transmitted contain the return code for the method. The return code is always in the form of one or more HTML pages. Most return codes include meta-keys that carry information about the data that is being transmitted.

Each POST request sent by a client application using Microsoft SharePoint Foundation or FrontPage Server Extensions from Microsoft includes a string that specifies the RPC method to execute and any parameters required for the method. For example, here is a sample POST that implements FrontPage Server Extensions:

Date: Thu, 03 Dec 2003 19:09:16 GMTCRLF
MIME-Version: 1.0CRLF
User-Agent: MSFrontPage/6.0CRLF
Host: server_nameCRLF
Accept: auth/sicilyCRLF
Authorization: Basic cm9iZjpUS3NvKjUwCRLF
Content-Length: 343CRLF
Content-Type: application/x-www-form-urlencodedCRLF
X-Vermeer-Content-Type: application/x-www-form-urlencodedCRLF

The previous example demonstrates the format sent by the client application. However, when you capture a POST using a program such as Network Monitor, it is displayed as follows:


The previous example shows a stream of data that is initially embedded in other code, as follows:

00000030 50 4F 53 54 20 2F 70 72 6F 64 
POST./site_url/ 00000040 39 38 2F 5F 76 74 69 5F 62 69 6E 2F 5F 76 74 69 
98/_vti_bin/_vti 00000050 5F 61 75 74 2F 61 75 74 68 6F 72 2E 64 6C 6C 20 
_aut/author.dll. 00000060 48 54 54 50 2F 31 2E 30 0D 0A 44 61 74 65 3A 20 
HTTP/1.0..Date:. 00000070 54 75 65 2C 20 31 39 20 4A 61 6E 20 31 39 39 39 
Tue,.19.Jan.2003 00000080 20 32 30 3A 33 35 3A 32 36 20 47 4D 54 0D 0A 4D 

To make this type of code more readable for use in the reference, several changes are made. First, code at the start of each line is stripped away to reveal the POST command. Then all the remaining line breaks are removed to form a stream of data. Next, line breaks are added back in to make it more readable. The periods (.) in this stream represent control characters or spaces and they too are removed. The following example shows the result of these changes, which still remains difficult to understand.

&listChildWebs=true &initialUrl=&platform=WinI386 

In final preparation for use in the Decoded section of a method topic, several more changes are made, resulting in the following format:

method=list+documents: &service_name=/allnew 
&listHiddenDocs=false &listExplorerDocs=false 
&listRecurse=false &listFiles=true 
&listFolders=true &listLinkInfo=true 
&listDerived=false &listBorders=false 
&listChildWebs=true &initialUrl= 
&platform=WinI386 &folderList=[;TW|09+Nov+2003+17:03:25+-0000]

The example shows the POST command as well as the method, and in this case the path for the POST command directs the post to author.dll. Ellipses (...) represent removed HTTP header lines. The method and its parameter values follow in a readable format.

Line breaks have been added to the Decoded sections for purposes of display in method topics.

For more information about the format in which to send a POST command, see Method Syntax.