3.1 Server responses

OK [<arbitrary debugging information>]

Request was successful.

ERR errorcode [<human readable error description>]

Request could not be fulfilled. The possible error codes are defined by libgpg-error.

S keyword <status information depending on keyword>

Informational output by the server, which is still processing the request. A client may not send such lines to the server while processing an Inquiry command. keyword shall start with a letter or an underscore.

# <string>

Comment line issued only for debugging purposes. Totally ignored.

D <raw data>

Raw data returned to client. There must be exactly one space after the ’D’. The values for ’%’, CR and LF must be percent escaped; these are encoded as %25, %0D and %0A, respectively. Only uppercase letters should be used in the hexadecimal representation. Other characters may be percent escaped for easier debugging. All Data lines are considered one data stream up to the OK or ERR response. Status and Inquiry Responses may be mixed with the Data lines.

INQUIRE keyword <parameters>

The server needs further information from the client. The client should respond with data (using the “D” command and terminated by “END”). Alternatively, the client may cancel the current operation by responding with “CAN”.

Consider the following examples (lines prefixed with S indicate text that the server sends; lines prefixed with C indicate text that the client sends):

S: INQUIRE foo
C: D foo bar
C: D bar baz
C: END
[Server continues normal work]

This implements a callback to the client:

S: INQUIRE foo
C: END
[Server continues]

and:

S: INQUIRE foo
C: CAN
[Server terminates the operaion and in most cases returns an ERR to the client.]

But, CAN may also mean “I have no data for you, try to get it from elsewhere.”

Note: lines longer than 1000 bytes should be treated as a communication error. (The rationale for having a line length limit is to allow for easier multiplexing of several channels.)