Name
restincl — Enduro/X HTTP REST incoming call handler (HTTP Server, XATMI Client)
DESCRIPTION
This is XATMI client which accepts HTTP/HTTPS REST requests, calls the XATMI server
specified in configuration. The binary works with go routines (very cheap threads).
But the number of concurrent invocations to XATMI sub-system is limited by workers
initialization configuration flag. In case if all workers are busy, the incoming thread
will wait for the XATMI worker to become free.
The configuration is defined in mixed for with INI and JSON formats. The
configuration file contains keys which value can be set as multi-line JSON.
Configuration file contains defaults key which defines the default parameters for
the route. Then when new route is added, firstly it is initialized from defaults
and then additionally it is overridden by route it self.
Incoming HTTP REST server (XATMI client), supports multiple buffer formats and
different error handling schemes. Buffer formats can be:
-
json2ubf - JSON Converted to UBF XATMI buffer type;
-
json2view - JSON Converted to VIEW XATMI buffer type;
-
json - JSON text directly set in UBF JSON buffer type;
-
text - XATMI Typed String buffer format. Incoming text is copied to String buffer;
-
raw - XATMI Carray buffer format; The incoming data is copied to Carray buffer type;
-
ext - UBF buffer is loaded with request body, headers and POST/PUT form values;
The error handling can be done in following ways:
-
http - mapped HTTP error codes are being used for indicating XATMI failure codes;
-
json - XATMI error codes are projected to JSON text root level two fields:
code and message;
-
text - The error code is printed in output response buffer text by using format
specified in config;
-
json2ubf - The error code is set in Enduro/X standard buffer fields and later
Converted to JSON buffer.
-
json2view - The error is converted to code/message fields specified for the view
errors. If views does not hold response field, the separate view name can be configured
in order to provide responses in error cases.
' ext - Special services and UBF buffers are used for handling the error cases.
The operation modes of the REST interface can by:
-
Synchronous - with http call XATMI services are invoked in Synchronous mode, waiting
for the sub-system answer or timeout that provides the corresponding response error
code.
-
Asynchronous - invocation does the asynchronous call to XATMI service. The answer
to http rest call is return of formatted error code and message. Indicating success
or fail of asyn service invocation.
The typical restincl configuration looks like:
[@restin]
port=8080
ip=0.0.0.0
#
# Defaults: conv=json2ubf
# async - call service in async way, if submitted ok, just reply back with ok
defaults={"errors":"http"
,"reqlogsvc": "GETFILE"
,"noreqfilersp": true
}
# Service 1
/svc1={"svc":"DATASV1", "notime":false, "conv":"json2ubf", "errors":"json", "async":false
,"errfmt_json_code":"\"error_code1\":%d"
,"errfmt_json_msg":"\"error_message1\":\"%s\""}
# Echo service:
/echo={"notime":false, "conv":"json2ubf", "errors":"json", "async":false, "echo":true}
HTTPS mode is also supported. In this case configuration file contains ssl certificate
file and key file. The format of these files are in x509 format.
It is possible to configure per request logging files. Then the parameter reqlogsvc
must be set which indicates the service name which to invocate to acquire the
request logging file name.
In case if multiple REST-IN handlers are needed with different binding IP/PORTS/HTTPS
settings. it is possible to use NDRX_CCTAG setting (environment or in client
process monitor configuration).
Next sections will describe supported buffer formats and it’s handling in the
Enduro/X.
Conversion buffer type: ext - External handling
External handling mode, incoming message is loaded into generic UBF fields. Field
names are following:
-
EX_IF_URL - URL called;
-
EX_IF_REQDATA - is loaded with HTTP Message body, byte array;
-
EX_IF_REQHN - request header names;
-
EX_IF_REQHV - request header values, same occurrence with names;
-
EX_IF_REQCN - request cookie names;
-
EX_IF_REQCV - request cookie value, same occurrence with names;
-
EX_IF_REQFORMN - form submit field names;
-
EX_IF_REQFORMV - form submit field values;
-
EX_IF_REQQUERYN - URL Query parameter names names;
-
EX_IF_REQQUERYV - URL Query parameter names values;
If fields are prepared OK, list of comma separated services found in finman
are executed with UBF buffer. This can be used to build up the target request buffer.
In case if any service fails from mandatory list, it is treated as general
error and then incoming error service chain finerr is executed (as optional).
When generating response EX_NETRCODE field with expected http code is read.
If field is missing in buffers, then restincl will respond with error 500,
without any body. In case of error and if buffer contains EX_NETRCODE, then
system will attempt to return the EX_IF_RSPDATA.
If there was no error, after all incoming filter chains done,
target service is executed. Once that is done, the response chain is activated.
If there was no error during target service call, the foutman mandatory chain
is executed. If it succeed, then optional chain foutopt chain is executed.
If there was error during the target service execution or mandatory out filter
chain execution (foutman), the fouterr service chain is executed.
If EX_NETRCODE is found in the body, then UBF content is used for response
generation and http status is set to EX_NETRCODE. If in case of error
EX_NETRCODE is not found, the response is set to 500 with out any content.
The response is generated in following way:
-
http body is loaded from EX_IF_RSPDATA;
-
http headers are loaded from EX_IF_RSPHN and EX_IF_RSPHV
-
http response cookies are loaded from EX_IF_RSPCN, EX_IF_RSPCV,
EX_IF_RSPCPATH, EX_IF_RSPCDOMAIN, EX_IF_RSPCEXPIRES, EX_IF_RSPCMAXAGE,
EX_IF_RSPCSECURE, EX_IF_RSPCHTTPONLY
-
http content type is according to ubftab.EX_IF_RSPHN (Content-Type) value
found in EX_IF_RSPHV. If Conent-Type is not provided in response, text/plain
is used.
NOTE: The conv mode works only with ext error handling mode. And error
handling mode ext works only with buffer conversion mode ext.
Conversion buffer type: json2ubf - JSON converted to UBF message handling
With JSON2UBF mode, it is expected that configured web service will receive JSON
document formatted in one level, where basically data is encode in key:value
format. Array’s types is supported. The array elements are loaded into UBF buffer
field occurrences. The BLOB elements are encoded as Base64 data and are loaded
into UBF buffer’s BFLD_CARRAY typed fields in decoded (binary form). If target field
is not BFLD_CARRAY, then it is treated as string data and loaded into field via
conversion functions.
The JSON2UBF POST REST data of service invocation of would look like:
{
"T_CHAR_FLD":"A",
"T_SHORT_FLD":123,
"T_LONG_FLD":444444444,
"T_FLOAT_FLD":1.33,
"T_DOUBLE_FLD":4444.3333,
"T_STRING_FLD":["HELLO", "WORLD"],
"T_CARRAY_FLD":"SGVsbG8="
}
That would be converted into following UBF buffer:
T_CHAR_FLD A
T_SHORT_FLD 123
T_LONG_FLD 444444444
T_FLOAT_FLD 1.33
T_DOUBLE_FLD 4444.3333
T_STRING_FLD HELLO
T_STRING_FLD WORLD
T_CARRAY_FLD Hello
When response is generated for caller, the UBF buffer coming back from Enduro/X IPC
would be in the same JSON format as in request - single level JSON document with
arrays if necessary i.e. have multiple occurrences for field.
The restincl for incoming data does not check the MIME type, but in response
MIME type will be set to: text/plain.
Conversion buffer type: json2view - JSON converted to VIEW message handling
With JSON2VIEW mode, it is expected that configured web service will receive JSON
document formatted in two levels, outer level is object with view name (which is
configured in Enduro/X environment VIEWDIR and VIEWFILES. The second level
of the JSON document basically is fields encoded in key:value format.
Array’s types is supported. The array elements are loaded into UBF buffer
field occurrences. The BLOB elements are encoded as Base64 data and are loaded
into VIEW buffer’s carray fields typed fields in decoded (binary form). The standard
UBF data conversation functions (CBchg(3)) are used for data converting.
The JSON2VIEW POST REST data of service invocation of would look like:
{
"MYVIEW":{
"char_fld":"a",
"short_fld":123,
"long_fld":444444444,
"float_fld":1.33,
"double_fld":4444.3333,
"string_fld":["hello", "world"],
"carray_fld":"SGVsbG8="
}
}
That would be converted into following VIEW buffer:
VIEW MYVIEW
#type cname fbname count flag size null
char char_fld - 1 - - -
short short_fld - 1 - - -
long long_fld - 1 - - -
float float_fld - 1 - - -
double double_fld - 1 - - -
string string_fld - 2 - 20 -
carray carray_fld - 1 - 25 -
# optional response fields, used if configured so:
string rspmessage - 1 - 255 -
short rspcode - 1 - - -
END
When response is generated for caller, the VIEW buffer coming back from Enduro/X IPC
would be in the same JSON format as in request - two level JSON document with
arrays if necessary i.e. have multiple occurrences for field.
The restincl for incoming data does not check the MIME type, but in response
MIME type will be set to: text/plain.
For error handling if configured so (using json2view errors), the restincl can
install the ATMI error code and message in the VIEW before converting to JSON,
Thus rspcode and rspmessage can be produced back in the JSON with corresponding
content. In case of wrong configuration (errfmt_view_rsp does not contain
response fields) or errfmt_view_rsp is not set at all, but error mechanism is
json2view and response view does not have response fields, the restincl will
generate {} - empty JSON object error. The caller shall assume this as format
error or timeout (because there are no knowledge to caller of what have happened
at the service).
Conversion buffer type: json - Direct JSON buffer
In this case JSON text is received in POST message and buffer is loaded into XATMI
buffer type JSON. Buffer is sent to target service. It is expected that target
service will respond with valid JSON text back which is returned in HTTP response.
In this case too, the response type is set to text/plain.
Conversion buffer type: text - Arbitrary text message
In this case arbitrary string is received from POST message. The string is loaded
into Enduro/X buffer type STRING. And with this buffer the message is delivered
to destination service (svc field from route configuration). The response also
is generated as pure string, with MIME set to text/plain.
Conversion buffer type: raw - BLOB message
In this case arbitrary binary (BLOB) data is received from POST message.
The BLOB is loaded inti CARRAY typed buffer and destination service is invoked
with this buffer. If service invocation is success, then the received BLOB message
from XATMI sub-system is returned to caller. In this case response will be generated
as application/octet-stream.
Error handling type: ext - external service mode
As described in buffer ext buffer conversion mode, this error handling mechanism
consists of following key features:
-
If incoming mandatory filters or buffer preparation fails,
then finerr services is called.
If after service calls buffer contains EX_NETRCODE (http code), then UBF buffer contents
are used for generating response. Otherwise http error code 500 is returned with
out any body.
-
If incoming filters where succeed, but target service or outgoing mandatory
filters did fail, the fouterr chain is executed. And in the same way if
EX_NETRCODE in final stages are present in buffer, then value from this is used
for http code and buffer contents are used for sending back responses. If return
code is not present, then error code 500 is returned, with any further processing.
Error handling type: http - return error codes in HTTP protocol
With this error handling method, the error codes are returned within HTTP protocol.
The error code can be mapped from XATMI subsystem to HTTP codes by using
errors_fmt_http_map parameter in service or default parameter block. The default
mapping which is set if errors_fmt_http_map is not present, is following:
-
atmi.TPMINVAL (0) = http.StatusOK (200)
-
atmi.TPEABORT (1) = http.StatusInternalServerError (500)
-
atmi.TPEBADDESC (2) = http.StatusBadRequest (400)
-
atmi.TPEBLOCK (3) = http.StatusInternalServerError (500)
-
atmi.TPEINVAL (4) = http.StatusBadRequest (400)
-
atmi.TPELIMIT(5) = http.StatusRequestEntityTooLarge (413)
-
atmi.TPENOENT (6) = http.StatusNotFound (404)
-
atmi.TPEOS (7) = http.StatusInternalServerError (500)
-
atmi.TPEPERM (8) = http.StatusUnauthorized (401)
-
atmi.TPEPROTO (9) = http.StatusBadRequest (400)
-
atmi.TPESVCERR (10) = http.StatusBadGateway (502)
-
atmi.TPESVCFAIL (11) = http.StatusInternalServerError (500)
-
atmi.TPESYSTEM (12) = http.StatusInternalServerError (500)
-
atmi.TPETIME (13) = http.StatusGatewayTimeout (504)
-
atmi.TPETRAN (14) = http.StatusInternalServerError (500)
-
atmi.TPERMERR (16) = http.StatusInternalServerError (500)
-
atmi.TPEITYPE (17) = http.StatusInternalServerError (500)
-
atmi.TPEOTYPE (18) = http.StatusInternalServerError (500)
-
atmi.TPERELEASE (19) = http.StatusInternalServerError (500)
-
atmi.TPEHAZARD (20) = http.StatusInternalServerError (500)
-
atmi.TPEHEURISTIC (21) = http.StatusInternalServerError (500)
-
atmi.TPEEVENT (22) = http.StatusInternalServerError (500)
-
atmi.TPEMATCH (23) = http.StatusInternalServerError (500)
-
atmi.TPEDIAGNOSTIC (24) = http.StatusInternalServerError (500)
-
atmi.TPEMIB (25) = http.StatusInternalServerError (500)
-
Anything else (\*) = http.StatusInternalServerError (500)
Error handling type: json - response code embedded JSON response message
This is suitable for json and json2ubf buffer types. On response the JSON
block is appended at then end with two fields. The fields are set with format
string %s for error message in errfmt_json_msg parameter, for example
"error_message":"%s". The error code format is set with %d in errfmt_json_code
parameter, for example: "error_code":%d. The error codes are XATMI standard defined
in xatmi.h. For example if calling JSON service and call times out, then response
will be look like:
{"error_code":13,"error_message":"13:TPETIME (last error 13: ndrx_mq_receive failed: Connection timed out)"}
Error handling type: json2ubf - UBF format field in JSON response message
With this error handling mechanisms, which is suitable for JSON2UBF buffer
conversion mode, the error message is loaded into top level JSON field EX_IF_ECODE
and error message is loaded into EX_IF_EMSG field. This is suitable in case if
using restout on the other Enduor/X server to bridge the servers using HTTP/Rest
method.
Error handling type: text - Free format text error code and message
The error code and message is generated in free form text which is provided by
errfmt_text service parameter block field. The first parameter in format string
must be %d - for XATMI error, and next parameter in format string must be %s-
for error message. For example errfmt_text could be set to %d: %s.
Error codes and it’s meaning
No matter of which error handling mechanism is selected http/json/json2ubf/text,
the list of Enduro/X error codes is following:
-
0 - Succeed (TPMINVAL)
-
1 - Transaction abort (TPEABORT)
-
2 - Bad call descriptor (TPEBADDESC)
-
3 - Blocking condition found (TPEBLOCK)
-
4 - Invalid parameters passed to function or service (TPEINVAL)
-
5 - System limit (TPELIMIT)
-
6 - Service not found (TPENOENT)
-
7 - Operating system error (TPEOS)
-
8 - No permissions (TPEPERM)
-
9 - Protocol error, service invoked in invalid order (TPEPROTO)
-
10 - Service hard failure, crashed (TPESVCERR)
-
11 - Service soft failure, returning error (TPESVCFAIL)
-
12 - System error (TPESYSTEM)
-
13 - Time out condition (TPETIME)
-
14 - Transaction error (TPETRAN)
-
16 - Resource manager error (TPERMERR)
-
17 - Invalid input data type to service (TPEITYPE)
-
18 - Invalid data type received from service (TPEOTYPE)
-
19 - Invalid program release (TPERELEASE)
-
20 - Transaction partially completed (TPEHAZARD)
-
21 - Transaction partially completed (TPEHEURISTIC)
-
22 - Event occurred, only for conversational messages, RFU (TPEEVENT)
-
23 - Identifier not matches (TPEMATCH)
-
24 - Diagnostic info provided, RFU (TPEDIAGNOSTIC)
-
25 - RFU (TPEMIB)
CONFIGURATION
-
port = PORT_NUMBER
-
Port number to listen on which http server will listen on. Mandatory option.
-
ip = IP_ADDRESS
-
Ip address on which http server is listening for incoming connections. Default
0.0.0.0.
-
workers = NUMBER_OF_XATMI_SESSIONS
-
Number XATMI sessions. These sessions are use for serving the incoming calls -
i.e. doing the calls to XATMI sub-system. If the number is less than incoming calls,
the calls will be suspended while there will be no XATMI session free. Once it is
made free, then call will be served (i.e. called corresponding XATMI counterpart).
The default value for parameter is 10.
-
gencore = GENERATE_CORE_FILE
-
If set to 1, then in case of segmentation fault, the core dump will be generated
instead of Golang default signal handler which just prints some info in stderr.
The default value is 0 which means use default Golang panic handling mechanisms.
-
tls_enable = ENABLE_HTTPS
-
With this setting set to 1, HTTPS will be enabled. Default value is 0. To complete
the HTTPS activation, configuration flags tls_cert_file and tls_key_file must
be set too. Otherwise program will run in HTTP mode.
-
defaults = 'SERVICE_CONFIGURATION_JSON*
-
This is JSON string (can be multiline), setting the defaults for the services. It
is basically a service descriptor which is used as base configuration for services.
Once the service is being setup, firstly it uses this defaults config block and
then overrides it by additional flags in service definition block. The details
within the JSON are described in bellow section SERVICE CONFIGURATION.
-
/some/service/url = 'SERVICE_CONFIGURATION_JSON*
-
This is the same configuration as for default, but describes the service route.
The REST-IN process might have as many as needed the service mapping routes.
SERVICE CONFIGURATION
-
svc = MAPPED_XATMI_SERVICE_NAME
-
This is the name of the target XATMI service which needs to be invoked when POST
message is received. The invocation might be synchronous, in which case caller will
wait for service to complete or receive XATMI time-out. If service completes, then
response is generated back to caller in configured format (conv parameter). If
service fails or times-out. The error is returned. Depending on error handling
mode (errors parameter), the data buffer can be returned too, including the
erroneous buffer data, because XATMI services at application level errors TPESVCFAIL
returns the data buffer from service even the error occurred. The data is returned
with error in case of following error handling methods: http, json, json2ubf.
-
errors = ERROR_HANDLING
-
The parameter can be set to following values http, json, json2ubf and text.
See the working modes of each of the modes in above text.
The default value for this parameter is json.
-
notime = NO_TIMEOUT
-
Set value to true if service call shall be run with out XATMI sub-system tpcall()
timeout value. Default is 0, meaning that standard timeout settings applies on
the destination service call.
-
errfmt_text = TEXT_BUFFER_ERROR_FORMAT_STRING
-
Format string for buffer to return in case if destination service invocation fails.
Format text will be invoked with "%d" representing the error code and then with
"%s" representing the error message. This error string is used in case if
errors parameter is set to text. The format string will be used only in case
of tpcall(3) error. If no error occurs, then service answer message is returned.
If case if asynchronous invocation is done to service (async param set to true),
the format string will be used, the status code will be returned, including 0
if tpacall(3) did succeed.
-
errfmt_json_msg = JSON_BUFFER_ERROR_FORMAT_STRING_MESSAGE
-
JSON error message field format string. Normally this would be set to JSON field like
syntax. This field is used in case if errors parameter is set to json.
The field is always present
in case of unsuccessful invocation of XATMI service. If service parameter errfmt_json_onsucc
is set to true, then field is present in case of successful XATMI service invocation
too. The field is present also in case of successful async service invocation
.e. if async is set to true.
The default value for the field is "error_message":"%s".
-
errfmt_json_code = JSON_BUFFER_ERROR_FORMAT_STRING_CODE
-
JSON message field format for presenting XATMI error code occurred while doing the
service invocation. This field is together with errfmt_json_msg field. The format
string for the field is %d, with meaning of XATMI error code.
The default value for this parameter is "error_code":%d.
-
errfmt_json_onsucc = ADD_JSON_ERROR_FIELDS_ON_SUCCEESS
-
If set to true, in case of successful synchronous service invocation, then error
fields defined in errfmt_json_msg and errfmt_json_code will be added to JSON
message ending.
-
errfmt_view_code = ERRFMT_VIEW_CODE
-
Field name into which store the response XATMI error code in case of json2view
errors. Parameter is mandatory for json2view error handling mechanism.
-
errfmt_view_msg = ERRFMT_VIEW_MSG
-
Field name into which store the response XATMI error message in case of json2view
errors. Parameter is mandatory for json2view error handling mechanism.
-
errfmt_view_onsucc = ERRFMT_VIEW_ONSUCC
-
If set to true, the restincl will try to install the errfmt_view_code and
errfmt_view_msg errors fields in the response buffer in case if call is success,
if fields are not found in the response buffer, the condition is ignored and pure
response buffer (converted to JSON) is returned. Default is true.
-
view_notnull = VIEW_NOTNULL
-
Do not convert NULL fields (according to view) to the outgoing JSON. For more
infos see, the tpjsontoview(3) or CBvget(3) man pages. Basically the functionality
will omit the matched NULL fields in the VIEW. In case of arrays, dropped will be
only last NULL fields, if there is some valid value in the middle and start is
filled with NULLs, then start NULLs will be converted to JSON anyway.
Default is false.
-
errfmt_view_rsp = ERRFMT_VIEW_RSP
-
View name to be used when sending the errors json2view errors. In case of 1)
if there is error and response buffer does not have error fields, view
errfmt_view_rsp will be instantiated and fields will set with the error code.
If errfmt_view_rsp is invalid, then response will contain {} - empty JSON
object. In that case the caller should threat the error as format error or timeout.
2) In case of async is set to true and asyncecho is set to false, in this
case errfmt_view_rsp is mandatory. 3) If errfmt_view_rsp_first is set, then
errfmt_view_rsp must be set too, as in this case error will be charged into
configured object.
-
errfmt_view_rsp_first = ERRFMT_VIEW_RSP_FIRST
-
If set to true, the system will instantiated errfmt_view_rsp view and set error
there instead of response view.
-
async = 'DO_ASYNC_SERVICE_INVOCATION*
-
Set to true if target service should be invoked asynchronously with TPNOREPLY
flag set, meaning that message is enqueued to service with out waiting for response.
Regardless of error reporting method set in errors parameter, the status of the
invocation is provided back to caller, by using the configured method.
The default value for parameter is false.
-
asyncecho = ECHO_BACK_BUFFER_DURING_ASYNC_INVOCATION
-
Set to true if on successful invocation, the request buffer shall be echoed back
to caller. In this case if service invocation was successful, the request buffer
is sent back to HTTP caller with no error fields set. In case if failure happened,
then corresponding error is reported back to caller with configured errors mechanism.
The default value for parameter is false.
-
conv = BUFFER_CONVERTION_TYPE
-
Request/response buffer conversion method. Available constants json2ubf, json,
text and raw. Buffer methods are described above in manpage. Shortly: json2ubf -
converts incoming JSON formatted document (with one level key:value (including arrays))
to Enduro/X UBF buffer format. json makes the JSON XATMI data buffer, text makes
STRING XATMI data buffer. The raw method load the data into CARRAY XATMI buffer.
The default value for this parameter is json2ubf. If static file serving is
required then conv type shall be set to "static". For static serving parameter
-
reqlogsvc = REQUEST_LOGGING_SERVICE
-
Request logging service. If the service name is set and buffer conversion type is
set to json2ubf, then when request is received and is converted to UBF XATMI
buffer type, the service is invoked by tplogsetreqfile(3) XATMI function. If
service returns EX_NREQLOGFILE UBF field, then current request logging is switched
to given request file. When service invocation is completed and data is returned
back to caller, the restincl will close the request logging by invoking
tplogclosereqfile(3). This mechanism is useful if per session or some other
correlator (for example banking card number (PAN) hash is used for separating the logs)
based logging is needed. Thus to employ the functionality fully, the target services
should use the request logging too.
The default value for this parameter is empty - not set.
-
errors_fmt_http_map = HTTP_ERROR_CODES_MAPPING
-
Error mapping between XATMI error code and HTTP. This is optional remap string
which will override the default mode described above. The parameter is effective
only in case if errors parameter is set to http. The syntax for the string
is following:
-
staticdir = STATIC_DIR_OF_FILES
-
In case if conv is set to static, then this parameter denotes the folder
where static contents is kept. Note that if file name at the route does not match,
then file server will attempt to to upload index.html. If index.html is not
available, then directory listing will be provided back to caller.
"errors_fmt_http_map":"<ATMI_ERROR_CODE_1>:<HTTP_STATUS_CODE_1>,...,
<ATMI_ERROR_CODE_N>:<HTTP_STATUS_CODE_N>,*:<HTTP_STATUS_CODE_FOR_ANY_OTHER>"
for example:
"errors_fmt_http_map":"13:404,*:200"
means that XATMI error code 13 (time-out)
will be mapped to HTTP status code 404. In case of any other XATMI error (*),
the HTTP status code will be set to 200.
The default value is as described above.
-
noreqfilersp = DO_NOT_SEND_REQUEST_FILENAME_BACK_TO_CALLER
-
If set to true, that will indicate the request logging file name shall not be
provided back in buffer to caller in response.
Default value for field is false, meaning that if conversion type is set to
json2ubf and request logging is used, then field EX_NREQLOGFILE will be provided
back in response to caller.
-
echo = ECHO_MODE
-
In echo mode the incoming request buffer is directly sent back to caller in response
message. This is useful for making link testing routines.
The default value for parameter is false.
-
format = ROUT_FORMAT
-
Format of the provided rout. Possible values: r, regexp. Default or empty means
that regexp compiler will not be used. r and regexp means that rout should have
regular expression which will be used to map url. Regular expression matching will
be used in case exact path is not found.
-
urlfield = URL_FIELD
-
Field to store URL path for json and json2ubf conversion methods in case regular
expression format is used. Default value is EX_IF_URL.
-
parseform = true|false
-
If set to true then URL and Post body is parsed and EX_IF_REQFORMN/EX_IF_REQFORMV
pairs are filled. In this case EX_IF_REQDATA field is not setup. This flag functions
only in conv/error mode ext.
-
finman = SERVICE_LIST
-
Comma separated list of services to call before target service invocation. This
is mandatory list. Any failed service will terminated request chain and error
will be returned. Default is empty.
-
finopt = SERVICE_LIST
-
Comma separated list of services to call before target service invocation. This
is optional list. Any failed service will be ignored and chain execution will
continue. Default is empty.
-
finerr = SERVICE_LIST
-
Comma separated list of services to be executed when in ext mode incoming
mandatory filters or buffer setup failed. In case if EX_NETRCODE is present,
it is assumed that buffer content is ready for response generation. This is
optional service list. Default is empty.
-
foutman = SERVICE_LIST
-
Comma separated list of services to be executed when in ext mode input filters
and target service was OK. This is mandatory list, any service error will trigger
fouterr chain to process.
-
foutopt = SERVICE_LIST
-
Comma separated list of services to be executed when in ext mode input filters,
target service was OK and foutman list were executed OK. This is optional list,
any service errors will be ignored.
-
fouterr = SERVICE_LIST
-
Comma separated list of services to be executed when in ext mode target service
or outgoing mandatory filters have failed. In case if EX_NETRCODE is present
(set by this or previous services), it is assumed that buffer content is ready
for response generation. This is optional service list. Default is empty.
STATIC ROUTES EXAMPLE
For example
/static.*={"svc":"@STATIC", "format":"regexp", "conv":"static", "staticdir":"${NDRX_APPHOME}/static"}
/={"svc":"@STATIC", "conv":"static", "staticdir":"${NDRX_APPHOME}/static"}
/index.html={"svc":"@STATIC", "conv":"static", "staticdir":"${NDRX_APPHOME}/static"}
will perform following logic:
-
sub-folder. For example /static/app1/test.ccs will be provided.
-
/ will strictly on root host provide only index.html from static
resources directory.
-
index.html in the same way if at host root index is access then, will be provided from
static folder.
EXIT STATUS
EXAMPLE
To see the usage different usage settings, see tests/01_restin/runtime/conf/restin.ini'.
SEE ALSO
restoutsv(8) tcpgatesv(8).