3.2.5.2 Responding to All Request Type Requests

The server can respond to all request type requests with a chunked response, as specified in section 2.2.2.2. If the entire response is not readily available, the server MUST use the Transfer-Encoding header, as specified in section 2.2.3.2.5, with a value of "chunked". Chunked transfer coding is specified in [RFC2616] section 3.6.1. The Transfer-Encoding header is used instead of the Content-Length header field as specified in section 2.2.3.2.1. By using "chunked" transfer coding, the server is able to return data to the client while the request is still being processed by the server. It also allows the server to return an amount of data to the client whose length is not determined when the initial response is returned. If the server is able to return the entire response immediately, it can chose to forgo the chunked response.

The response includes all Set-Cookie headers as specified in section 2.2.3.2.3 associated with the Session Context.

After the request has been authorized, authenticated, parsed, and validated, the server MUST return a X-ResponseCode with a value of 0 (zero) to indicate that the request has been accepted. The server MUST respond immediately to a request while the request is being queued and processed by the server. The initial response includes the PROCESSING meta-tag, as specified in section 2.2.7. If the server is using the "chunked" transfer coding, it MUST flush this to the client (being careful to make sure it disables any internal Nagle algorithms, as described in [RFC896], that might attempt to buffer response data).

Beyond the initial immediate response, the server MUST also periodically return a keep-alive response to the client to let the client know that the request is still being processed. The server maintains a keep-alive timer as specified in section 3.2.2 that, when expired, causes the server to send a keep-alive response to the client. The keep-alive response includes the PENDING meta-tag, as specified in section 2.2.7. Since the keep-alive interval is configurable or auto-adjusted, the server MUST return the X-PendingPeriod header, specified in section 2.2.3.3.5, within the immediate response to tell the client the number of milliseconds to be expected between keep-alive responses from the server during the time a request is currently being executed on the server.

After the server finishes processing the request it finishes with the DONE meta-tag, as specified in section 2.2.7; followed by any additional response headers. The X-ElapsedTime and X-StartTime are present after the DONE meta-tag, as specified in section 2.2.3.3.9 and 2.2.3.3.10 respectively. The server will include a X-ResponseCode header, as specified in section 2.2.3.3.3, if a failure occurs after the initial response is sent. More specifically, this gives the server the ability to later fail the request and return a different value in the X-ResponseCode header. The request type response body for the initiating request type will immediately follow any additional headers preceded by a CRLF on an empty line. If an additional X-ResponseCode header is returned and if it indicates a failure, then the response body can be empty or can include failure data in a format that is specified by an additional Content-Type header as specified in section 2.2.3.2.2.

An example of the request and response using the Execute request type is described in section 4.2.