3.1.5.3.7 get documents

  • Article

The get documents request is used by the client to retrieve a set of documents for viewing on a client computer.

Tokens

service_name: This parameter is deprecated. See service_name in section 3.1.5.3.1.

url_list: A VECTOR-STRING list of service-relative URLs specifying what documents will be retrieved by the current request.

effective_protocol_version: This parameter has the same semantics as effective_protocol_version in get document (section 3.1.5.3.6).

old_theme_html: This parameter has the same semantics as old_theme_html version in get document.

expandWebPartPages: A BOOLEAN reserved for future use. This parameter MUST be ignored by the server regardless of a TRUE or FALSE value. The client MUST send false for this parameter either explicitly or by omitting the parameter.

validateWelcomeNames: For semantics, see section 3.1.5.3.1.

URL

FPAuthorScriptUrl

Return Values

The server MUST return a multipart/mixed MIME document ([RFC1341]), and the responses MUST be in URL Mode rather than HTML Mode.

Each part of the response MUST be one of the following three types: UrlArgs part, DocInfo part, or DocData part. These types are defined and scoped to this section; they exist merely to provide convenient names for the concepts.

The response MUST begin with a UrlArgs part. After the first part, each part determines the type of the next part as shown in the following illustration.

Type encoding sequence for get documents response

Figure 3: Type encoding sequence for get documents response

UrlArgs part: The UrlArgs part of the response MUST have a content-type of application/x-www-form-urlencoded and MUST have a METHOD-KEY-VALUE whose REQUEST-NAME-STRING is "get documents" followed by a RET-NAME/RET-VAL pair whose RPC-KEY-STRING is "current_time" and whose RPCVALUE is a TIME.

"method" VALSEP "get documents" ":" PROTOCOL-VERSION-STRING

ARGSEP "current_time" TIME LF

The UrlArgs part MUST either be followed by a DocInfo part or the response MUST end.

DocInfo part: The DocInfo part MUST be application/x-www-form-urlencoded and be a DOC-INFO-REQUEST. Each DocInfo part MUST be followed by a DocData part.

DocData part: The DocData part MUST have a Content-Type of application/octet-stream. It MUST contain the stream of the document corresponding to the previous DocInfo part. Each DocData part MUST be followed by a DocInfo part or the response MUST terminate.

Note The mf-file-status metadata MUST be added to the METADICT returned in the response. If it is nonzero, the remainder of the response SHOULD be discarded by the client. This key is not considered metadata about the file but rather metadata about the transport, which the client SHOULD examine and SHOULD remove before passing on the METADICT to higher layers.