MIMIC® Online Documentation

<< Previous Section    Next Section >>

MIMIC WEB Services Module Guide

  1. Table of Contents

  2. Overview

    The MIMIC WEB Services Module is an optional facility that simulates the standard web services via SOAP , XML , OpenAPI , REST , WBEM , WS-MAN , Redfish and many other API types.

    On Windows, it additionally supports SPNEGO-based Kerberos and NTLM HTTP Authentication.

    Back to Top

  3. Installation

    Web services support is made available in MIMIC as an optional dynamically loadable module. Starting with MIMIC 13.00, you can use the Protocol Wizard to install the WEB module. If you prefer to enable WEB by hand, you need to do the following:

    • Use File->Terminate to stop the any running MIMIC daemon.

    • Copy the WEB shared library (web.dll on Windows, web.so on Unix) from "bin/dynamic/optional" to "bin/dynamic" in the install directory.

    • Install the license keys as detailed in the instructions e-mailed to you.

    • Restart MIMIC. You should see the following type of message in the MIMICLog that confirms that the WEB module was properly loaded : 
      INFO  - WEB : Loaded protocol from < path-to-DLL >
INFO  - WEB v13.00

    Once WEB is loaded, any agent instance configured to support the web services will be able to handle web services requests.

    Back to Top

  4. Using WEB from MIMICView

    If the WEB module is enabled, then Agent->Add, Agent->Configure and Agent->Paste dialogs will display WEB as an additional checkbox in the Advanced pane along with the SNMP protocols. On selecting the checkbox a new WEB pane will appear.

    This WEB configuration pane lets the user configure the parameters for a WEB session:

    • Port

      This optional parameter specifies the port at which the server will be listening. The default is the standard port 80.

    • Use persistent connections

      This specifies whether connections are persistent. Default is true. The vast majority of connections are persistent according to Wikipedia but for the rare server that isn't, you need to set this to false.

    • Rule File

      This optional parameter specifies the rules that govern the web sessions to this agent. The rule file is in scripts/web/, and in effect implements a pattern match against web requests. Each rule consists of a regular expression that is matched against the URL in the request, and a response that is replied. Regular expressions are matched in the order they appear in the file, thus more generic regular expressions should be placed after more specific regular expressions, else they will take precedence. A sample rule file is shipped as sample.rul. Details can be found below.

    • WSDL File

      This optional parameter specifies the WSDL syntax of requests to this web service. The compiled WSDL file is in scripts/web/.

    • Username

      The username for access control. Blank will allow all access.

    • Password

      The password for access control. Blank will allow all access.

    • SSL Certificate File

      A WEB protocol enabled agent, can support HTTP-Secured communication using a Server Certificate. Select a certificate file to be used as Server Certificate here. If none is specified, the server.pem shipped with MIMIC is used by default.

    • Chunking Threshold

      The HTTP Transfer-Encoding: header is used to indicate how the contents will be transferred. The "chunked" encoding is used to transfer large contents by splitting it into manageable chunks. A positive integer value will enable chunking for responses larger than the specified threshold. Chunking is disabled by default (indicated by value 0).

    Back to Top

  5. Using WEB from MIMICShell

    A few new commands and some enhanced old commands can be used from the MIMICShell to control the WEB functionality. Here is a synopsis:

    • mimic protocol msg WEB get args

      This command lets the user gather the self-defining list of arguments required and their particulars. The parameters are detailed above. A sample exchange for this command would be: 

      mimicsh> mimic protocol msg WEB get args
{{port} {Port} {integer} {} {optional} {80}}
{{is_persistent_connections} {Use persistent connections} {boolean} {} {optional} {true}}
{{rule} {Rule File} {file} {scripts/web {{*.rul {web rule files} {edit yes} {new yes}}} -
both} {optional} {}}
{{wsdl} {WSDL File} {file} {scripts/web {{*.cwd {compiled WSDL files} {edit no} {new no}}} -
both} {optional} {}} 
{{username} {Username(blank for all-access)} {string} {} {optional} {}}
{{password} {Password(blank for all-access)} {string} {} {optional} {}}

    • mimic agent get protocol

      This command lets the user look at the protocols currently configured on the agent. A sample exchange for this command would be: 

        mimicsh> mimic agent get protocol
  snmpv1,snmpv2c,WEB

    • mimic agent set protocol

      This command lets the user change the protocol setting for an agent. A sample exchange for this command would be: 

        mimicsh> mimic agent get protocol
  snmpv1
  mimicsh> mimic agent set protocol snmpv1,WEB
  mimicsh> mimic agent get protocol
  snmpv1,WEB

    • mimic agent protocol msg WEB get config

      This command lets the user get the current argument settings. A sample exchange for this command would be: 

        mimicsh> mimic agent protocol msg WEB get config
  {port=80} {is_persistent_connections=true} {rule=hello.rul} {wsdl=AXLAPI.cwd} 
  {username=} {password=}

    • mimic agent protocol msg WEB set config [config]

      This command lets the user change the current argument settings of all WEB sessions for an agent. A sample exchange for this command would be: 

        mimicsh> mimic agent protocol msg WEB get config
  {port=80} {rule=hello.rul} {wsdl=AXLAPI.cwd} 

  mimicsh> mimic agent protocol msg WEB set config rule=sample_cuom.rul

  mimicsh>  mimic agent protocol msg WEB get config
  {port=80} {is_persistent_connections=true} {rule=sample_cuom.rul} {wsdl=AXLAPI.cwd} 
  {username=} {password=}

    • mimic agent protocol msg WEB get trace
      mimic agent protocol msg WEB set trace [0 or 1]

      This command lets the user change the WEB tracing configuration for an agent. A sample exchange would be: 

        mimicsh> mimic agent assign 2

  mimicsh> mimic agent protocol msg WEB get trace
  0
  mimicsh> mimic agent protocol msg WEB set trace 1

  mimicsh> mimic agent protocol msg WEB get trace
  1
      and the log would show: 

      INFO  01/23.11:45:35 - agent 2 trace enabled for WEB
INFO  09/13.13:32:28 - WEB[AGT=2,CON=4,REM=10.0.0.2:46845]: connection request received
INFO  09/13.13:32:28 - WEB[AGT=2,CON=4,REM=10.0.0.2:46845]: received 403 byte(s) data in pkt #1
INFO  09/13.13:32:28 -    47 45 54 20  2F 20 48 54  54 50 2F 31   GET / HTTP/1
INFO  09/13.13:32:28 -    2E 31 0D 0A  48 6F 73 74  3A 20 31 30   .1..Host: 10
INFO  09/13.13:32:28 -    2E 30 2E 30  2E 32 0D 0A  55 73 65 72   .0.0.2..User
INFO  09/13.13:32:28 -    2D 41 67 65  6E 74 3A 20  4D 6F 7A 69   -Agent: Mozi
INFO  09/13.13:32:28 -    6C 6C 61 2F  35 2E 30 20  28 58 31 31   lla/5.0 (X11
INFO  09/13.13:32:28 -    3B 20 55 3B  20 4C 69 6E  75 78 20 69   ; U; Linux i
INFO  09/13.13:32:28 -    36 38 36 3B  20 65 6E 2D  55 53 3B 20   686; en-US; 
INFO  09/13.13:32:28 -    72 76 3A 31  2E 39 2E 32  2E 32 34 29   rv:1.9.2.24)
INFO  09/13.13:32:28 -    20 47 65 63  6B 6F 2F 32  30 31 31 31    Gecko/20111
INFO  09/13.13:32:28 -    31 30 38 20  46 65 64 6F  72 61 2F 33   108 Fedora/3
INFO  09/13.13:32:28 -    2E 36 2E 32  34 2D 31 2E  66 63 31 34   .6.24-1.fc14
INFO  09/13.13:32:28 -    20 46 69 72  65 66 6F 78  2F 33 2E 36    Firefox/3.6
INFO  09/13.13:32:28 -    2E 32 34 0D  0A 41 63 63  65 70 74 3A   .24..Accept:
INFO  09/13.13:32:28 -    20 74 65 78  74 2F 68 74  6D 6C 2C 61    text/html,a
INFO  09/13.13:32:28 -    70 70 6C 69  63 61 74 69  6F 6E 2F 78   pplication/x
INFO  09/13.13:32:28 -    68 74 6D 6C  2B 78 6D 6C  2C 61 70 70   html+xml,app
INFO  09/13.13:32:28 -    6C 69 63 61  74 69 6F 6E  2F 78 6D 6C   lication/xml
INFO  09/13.13:32:28 -    3B 71 3D 30  2E 39 2C 2A  2F 2A 3B 71   ;q=0.9,*/*;q
INFO  09/13.13:32:28 -    3D 30 2E 38  0D 0A 41 63  63 65 70 74   =0.8..Accept
INFO  09/13.13:32:28 -    2D 4C 61 6E  67 75 61 67  65 3A 20 65   -Language: e
INFO  09/13.13:32:28 -    6E 2D 75 73  2C 65 6E 3B  71 3D 30 2E   n-us,en;q=0.
INFO  09/13.13:32:28 -    35 0D 0A 41  63 63 65 70  74 2D 45 6E   5..Accept-En
INFO  09/13.13:32:28 -    63 6F 64 69  6E 67 3A 20  67 7A 69 70   coding: gzip
INFO  09/13.13:32:28 -    2C 64 65 66  6C 61 74 65  0D 0A 41 63   ,deflate..Ac
INFO  09/13.13:32:28 -    63 65 70 74  2D 43 68 61  72 73 65 74   cept-Charset
INFO  09/13.13:32:28 -    3A 20 49 53  4F 2D 38 38  35 39 2D 31   : ISO-8859-1
INFO  09/13.13:32:28 -    2C 75 74 66  2D 38 3B 71  3D 30 2E 37   ,utf-8;q=0.7
INFO  09/13.13:32:28 -    2C 2A 3B 71  3D 30 2E 37  0D 0A 4B 65   ,*;q=0.7..Ke
INFO  09/13.13:32:28 -    65 70 2D 41  6C 69 76 65  3A 20 31 31   ep-Alive: 11
INFO  09/13.13:32:28 -    35 0D 0A 43  6F 6E 6E 65  63 74 69 6F   5..Connectio
INFO  09/13.13:32:28 -    6E 3A 20 6B  65 65 70 2D  61 6C 69 76   n: keep-aliv
INFO  09/13.13:32:28 -    65 0D 0A 43  61 63 68 65  2D 43 6F 6E   e..Cache-Con
INFO  09/13.13:32:28 -    74 72 6F 6C  3A 20 6D 61  78 2D 61 67   trol: max-ag
INFO  09/13.13:32:28 -    65 3D 30 0D  0A 0D 0A                   e=0....
INFO  09/13.13:32:28 - WEB[AGT=2,CON=4,REM=10.0.0.2:46845]: sending 267 byte(s) data in pkt #1
INFO  09/13.13:32:28 -    48 54 54 50  2F 31 2E 31  20 32 30 30   HTTP/1.1 200
INFO  09/13.13:32:28 -    20 4F 4B 0D  0A 43 61 63  68 65 2D 43    OK..Cache-C
INFO  09/13.13:32:28 -    6F 6E 74 72  6F 6C 3A 20  70 72 69 76   ontrol: priv
INFO  09/13.13:32:28 -    61 74 65 0D  0A 45 78 70  69 72 65 73   ate..Expires
INFO  09/13.13:32:28 -    3A 20 57 65  64 2C 20 33  31 20 44 65   : Wed, 31 De
INFO  09/13.13:32:28 -    63 20 31 39  36 39 20 31  39 3A 30 30   c 1969 19:00
INFO  09/13.13:32:28 -    3A 30 30 20  45 53 54 0D  0A 43 6F 6E   :00 EST..Con
INFO  09/13.13:32:28 -    74 65 6E 74  2D 54 79 70  65 3A 20 74   tent-Type: t
INFO  09/13.13:32:28 -    65 78 74 2F  68 74 6D 6C  3B 63 68 61   ext/html;cha
INFO  09/13.13:32:28 -    72 73 65 74  3D 49 53 4F  2D 38 38 35   rset=ISO-885
INFO  09/13.13:32:28 -    39 2D 31 0D  0A 43 6F 6E  74 65 6E 74   9-1..Content
INFO  09/13.13:32:28 -    2D 4C 65 6E  67 74 68 3A  20 35 35 0D   -Length: 55.
INFO  09/13.13:32:28 -    0A 44 61 74  65 3A 20 57  65 64 2C 20   .Date: Wed, 
INFO  09/13.13:32:28 -    32 32 20 4D  61 79 20 32  30 31 33 20   22 May 2013 
INFO  09/13.13:32:28 -    32 30 3A 31  38 3A 35 30  20 47 4D 54   20:18:50 GMT
INFO  09/13.13:32:28 -    0D 0A 43 6F  6E 6E 65 63  74 69 6F 6E   ..Connection
INFO  09/13.13:32:28 -    3A 20 63 6C  6F 73 65 0D  0A 53 65 72   : close..Ser
INFO  09/13.13:32:28 -    76 65 72 3A  0D 0A 0D 0A  3C 68 74 6D   ver:....<htm
INFO  09/13.13:32:28 -    6C 3E 3C 62  6F 64 79 3E  3C 68 33 3E   l><body><h3>
INFO  09/13.13:32:28 -    57 65 6C 63  6F 6D 65 20  74 6F 20 68   Welcome to h
INFO  09/13.13:32:28 -    65 6C 6C 6F  2E 72 75 6C  3C 2F 68 33   ello.rul</h3
INFO  09/13.13:32:28 -    3E 3C 2F 62  6F 64 79 3E  3C 2F 68 74   ></body></ht
INFO  09/13.13:32:28 -    6D 6C 3E                                ml>
INFO  09/13.13:32:28 - WEB[AGT=2,CON=4]: disconnecting connection
...

    • mimic protocol msg WEB get stats_hdr
      mimic agent protocol msg WEB get statistics

      Returns WEB statistics information:

      • a list of statistic headers, and
      • current statistics values for the specified server.

      In order, the statistic values are:

      • Total number of connections established.
      • Total number of disconnects.
      • Total number of packets sent out.
      • Total number of packets received.
      • Total number of HTTP/HTTPS requests received.
      • Total number of HTTP/HTTPS requests processed/responded.
      • Total number of responses generated using only WSDL.
      • Total number of responses generated using only rule based information.
      • Total number of responses generated using combination of WSDL and rule based processing.

      A sample exchange for these commands would be: 

        mimicsh> mimic protocol msg WEB get stats_hdr
  {{connect} {Connect}} {{disconnect} {Disconnect}}
  {{pktSnt} {PktsSent}} {{pktRcvd} {PktsRcvd}}
  {{request} {Requests}} {{response} {Responses}}
  {{wsdlonly} {WSDLOnly}} {{ruleonly} {RuleOnly}} {{rulewsdl} {Mixed}} 

  mimicsh> mimic agent protocol msg WEB get statistics
  4 3 2 4 4 4 0 0 0

    • mimic agent protocol msg WEB server get state

      This command lets the user query the state of the server. This is particularly useful at agent startup time to wait for web server startup. A sample exchange for this command would be: 

        mimicsh> mimic agent protocol msg WEB server get state
  0
  mimicsh> mimic agent start

  mimicsh> while { ! [mimic agent protocol msg WEB server get state] } {
  	sleep 1
  }

    • mimic agent protocol msg WEB port exists ...
      mimic agent protocol msg WEB port add ...
      mimic agent protocol msg WEB port set ...
      mimic agent protocol msg WEB port start ...
      mimic agent protocol msg WEB port stop ...
      mimic agent protocol msg WEB port remove ...

      This set of commands manipulates extra ports for the WEB server. This allows to add extra service ports for the server, besides the default port in the server configuration. For example, to add a default SSL port would be: 

        mimicsh> if { ! [mimic agent protocol msg WEB port exists 443] } {
	mimic agent protocol msg WEB port add 443
	mimic agent protocol msg WEB port set 443 ssl ssl23
	mimic agent protocol msg WEB port start 443
  }

      The config/web/server.pem that ships with MIMIC is a sample SSL configuration that illustrates the format for a certificate chain and private key that the MIMIC WEB server accepts. It will only work with clients that accept non-matching credentials, such as curl --insecure. As such, it will never work for any arbitrary common name (CN) that you want to use. If your client cares about valid certificates, you must create your own.

    Back to Top

  6. Recording WEB Sessions

    7. The WEB Wizard provides a user-friendly GUI to create WEB simulations from a real-world WEB session / conversation. This section documents the utilities used by the wizard, in case you want to use them from the command line.

    To create a default simulation, you have 2 options:

    • webrec

      You can record a web conversation between a WEB client and server with the webrec utility. This tool works as a proxy between client and server, and saves requests and responses in a temporary web session file.

      This section documents the command-line options to this utility

      • --outfilename output-file

        this mandatory argument specifies the output file name.

      • --port port

        this optional argument specifies a port to listen for cleartext requests, by default 80.

      • --ssl-port port

        this optional argument specifies a port to listen for encrypted requests, by default 443.

      • --dest-ip

        this mandatory argument specifies a host-address of the web server.

      • --dest-port port

        this mandatory argument specifies a port on the web server to forward cleartext requests.

      • --dest-ssl-port port

        this mandatory argument specifies a port on the web server to forward encrypted requests.

      • --servercert

        Certificate PEM file to use as a server

      • --clientcert

        Certificate PEM file to use as a client

      • --cacert

        Certificate file issued by CA

      • --addr

        Bind to IP address (default - all)

      • --max-threads

        Maximum number of threads (default - 10)

      • --outfolder

        Absolute directory path for downloaded file

      • --overwrite

        Overwrite the existing files YES/NO (default - NO)

      • --debug

        Debug dump OFF/ON (default - OFF)

    • webpcap

      If you have a packet capture (PCAP) file of a web session from of the widely available network tools, such as WireShark, tcpdump, etc., you can run it through the webpcap, which saves requests and responses in a temporary web session file.

      This section documents the command-line options to this utility

      • --file input-file

        this mandatory argument specifies the input PCAP file name. Note: only PCAP files are supported, not pcapng or other PCAP style files.

      • --out output-file

        this optional argument specifies the output file name. By default, this is the input file name appended with .txt.

      • --target host-address

        this optional argument specifies a host-address of the web server. By default, this is the first web server found in the PCAP.

      • --port port

        this optional argument specifies a port to listen for cleartext requests, by default the first port with a WEB request.

      • --start start
      • --stop stop

        with these 2 optional parameters you can specify a range of packets to be recorded. By default, all packets will be recorded.

      • --directory directory-path

        this optional argument specifies the directory path where the output file(s) will be placed. By default, this is the folder that contains the input file.

    The conversation file that was created by the above webrec or webpcap utility is then run through the WEB converter webconv to create a default WEB simulation.

    Back to Top

  7. Simulation Configuration

    8. The definitions that govern the WEB module simulation are encoded in the rule file. This is a ASCII text file that is configured for a WEB server instance, and defines the behavior of the WEB simulation.

    The rules database is located in the scripts/web/ directory in the MIMIC directory hierarchy. The MIMIC distribution comes with an example file sample_cuom.rul.

    NOTE: rules and script files are cached, and modifications to them will only be reloaded by the parser when the rule file modification time is newer than what is in the cache.

    Back to Top

    Rule File Format

    The rules database defines the rules for the WEB services served by an agent instance. It is made up of a series of service blocks. A typical rules database will look something like: 

    version = 13.00

include = {
     rules = some-rules.rul
     tcl = some-include.mtcl
}

    The include block does inline expansion of both rule files, eg. above the other file some-rules.rul is added to this rule file, or Tcl scripts, eg. above the file some-include.mtcl contains additional scripts. 

    service = {
        url_pattern = /pattern
        # multiple values can be specified by space separation
        http = HTTP ports to listen the service. e.g "8082 8083"
        https = HTTPS ports to listen the service. e.g "443 8443"
        server_cert = server certificate file with relative path to this file
        web_sim_dir_path = path relative to this file where simulation files are located
        dbpath = path relative to this file where xml database files are located

        runtime = {
                tcl = name of mtcl file
        }

        wsdlfile = name of compiled wsdl file
        porttype = name of portType in wsdl
}

    The service block specifies a service to be served at the particular URL pattern. If no url_pattern is specified, it defaults to /.

    Either http or https must be specified.

    If https is specified, then server_cert may or may not be specified. If not specified then the default server.pem will be used.

    Either rule, rulefile, wsdlfile or redirect should be specified. If none is specified then an error message will be displayed. 

    # compiled wsdl to be used with this rule file
wsdl = {
     file = enterprise/cisco/AXLAPI.cwd
     port = AXLPort
}

    The wsdl block specifies the compiled WSDL file (.cwd file) that the current rule file uses to handle commands. An optional port specifies the listening port for connections. 

    # runtime handling for initialization and cleanup
runtime = {
     tcl = runtime.mtcl
}

    The runtime block defines runtime handlers in runtime.mtcl. Currently, there are handlers for agent initialization and cleanup. At agent startup, the init proc defined in runtime.mtcl is called, and at agent stop, the cleanup proc is called.

    A request is matched in one of 3 ways:

    1. request =

      This matches a SOAP command. The request needs to be an exact string match, no pattern matching. 

      rule = {
     request = Body/getBillingServer
     response = <?xml version="1.0" encoding="UTF-8"?>
     response = <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns1="http://www.cisco.com/AXL/API/9.0">
     response =    <soap:Body>
     response =       <ns1:getBillingServerResponse/>
     response =    </soap:Body>
     response = </soap:Envelope>
}

      This rule block specifies a single command and hardcodes the response.

      These are sample curl commands and their outcome: 

      curl -X POST --data '<?xml version="1.0"?><soap:Envelope><soap:Body><getBillingServer>
</soap:Body></soap:Envelope>' http://10.9.201.134/abc
      matches 

      curl -X POST --header 'Content-Length: 0' http://10.9.201.134/abc
      does not match 

      curl -X POST --data '<?xml version="1.0"?><soap:Envelope></soap:Body></soap:Envelope>'
http://10.9.201.134/abc
      does not match 

      rule = {
     request = Body/getSNMPCommunityString
     response_update = SNMPCommunityString/communityName public-cucm
     response_update = SNMPCommunityString/version 1
     response_update = SNMPCommunityString/accessPrivilege ReadOnly
}

      When using a WSDL .cwd file in conjunction with the current rule file, the response_update command allows the inline patching of a XML branch in the command's response.

      The response_update command also allows scripting of results.

      • response_update = script

        Use this directive to script a specific XML branch's content. Example: 

             response_update = script sample_cuom.mtcl::get_SNMPCommunityString_accessPrivilege

      • response_update = xpath script

        Use this directive to script multiple XML branches. Example: 

             response_update = return script sample_cuom.mtcl::getServiceParameter

        Notice the return string is actually a XPath string that matches all XML tag <return>. 

        rule = {
     request = Body/listProcessNode
     response = <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns1="http://www.cisco.com/AXL/API/9.0">
     response =    <soap:Body>
     response =       <ns1:listProcessNodeResponse>
     response =          <return>
           # empty element will be filled by script
     response =          </return>
     response =       </ns1:listProcessNodeResponse>
     response =    </soap:Body>
     response = </soap:Envelope>
     response_script = sample_cuom.mtcl::listProcessNode
}

        Use the response_script command to create a general scripted response.

    2. request_header =

      Matches a HTTP command URI. The first line of the request's HTTP header lines needs to exactly match the field, case sensitive. 

      rule = {
     request_header = GET /ccmadmin/showHome.do;jsessionid=F959510A1266BD0CDAED2F5359402C9A
HTTP/1.1
     response_file = ccmadmin/showHome.do
}

      Use the request_header and response_file commands to handle non-SOAP HTTP commands, such as the GET command. This can be used in HTTP file transfer. 

      rule = {
     request_header = GET /ccmadmin HTTP/1.1
     response_header = HTTP/1.1 302 Moved Temporarily
     response_header = Location: http://192.9.200.3/ccmadmin/
     response_header = Date: Wed, 22 May 2013 20:17:27 GMT
     response_header = Server:
     response_header =
     response_header = 0
     response_header =
}

      When used in conjunction with request_header, this rule block can create a HTTP redirect. Some NMS applications rely on HTTP redirect.

      The response_content_type attribute sets the Content-Type of the response header, eg. 

      rule = {
	request_header = GET /redfish/v1/systems HTTP/1.1

	response_file = /redfish/v1/systems/mimic_1.html
	request_accept = application/json
	response_content_type = application/json
	is_persistent_connection = false
}

      The response_content command can be added in the context of a response_header. The reason you may want to use response_content is because lines in response_header are concatenated with the RFC7230 standard CRLF line delimiter while response_content allows the option of choosing LF character as the line delimiter, eg. 

      rule = {
request_header = GET /restconf/data/Cisco-IOS-XE-app-hosting-cfg:app-hosting-cfg-data/ HTTP/1.1
response_header = "HTTP/1.1 200 OK"
response_header = "Content-Length: 108"
response_header = "Content-Type: application/json"
response_header =
response_content = "{"
response_content = "  "Cisco-IOS-XE-app-hosting-cfg:app-hosting-cfg-data": {"
response_content = "    "apps": {"
response_content = "      "app": ["
response_content = "      ]"
response_content = "    }"
response_content = "  }"
response_content = "}"
response_content = ""
response_content_delimiter = LF
}

      With the request_accept attribute you can control the response of different content types to a query, based on the client's Accept: attribute in the request header. If a rule that otherwise matches the request, also matches a specified content in the request header Accept: statement, then that rule will be used to return the response.

      Use the response_header_script command to create a highly customized, scripted response. For example,

      Notice that for this request, the connection is not persistent, as specified with the is_persistent_connection attribute. 

      rule = {
	request_header = GET /ast/AstIsapi.dll?GetAlertLog&IsInitialRequest=0 HTTP/1.1
	response_header_script = sample_cucm.mtcl::astisapiGetAlertLogIsInitialRequest0
}

      You can customize HTTP redirects and HTTP authorizations in a response_header_script script. For example, 

      proc astisapiGetAlertLogIsInitialRequest0 { } {
	set response "<?xml version=\"1.0\"?>"
        set ret "HTTP/1.1 200 OK\r\n"
        append ret "Content-Type: text/xml;\r\n"
	append ret "Date: Wed, 22 May 2013 20:18:50 GMT\r\n"
	append ret "Server:  \r\n"
	append ret "\r\n"
	return $ret
}

      To allow HTTP chunking in a response, omit the "Transfer-Encoding:" and "Content-Length:" fields. Web.so will automatically fragment the response, as so, 

      proc astisapiGetAlertLogIsInitialRequest0 { } {
	set response "<?xml version=\"1.0\"?>"
	set ret "HTTP/1.1 200 OK\r\n"
	append ret "Content-Type: text/xml;\r\n"
	append ret "Date: Wed, 22 May 2013 20:18:50 GMT\r\n"
	append ret "Server:  \r\n"
	append ret "\r\n"
	return $ret
}

    3. request_type =

      Matches a HTTP command (GET, POST, ...). This rule takes all the matching HTTP commands, and allows to call a script that handles pattern matching of URLs. 

      rule = {
request_type = POST
response_header_script = myrule.mtcl::common_handler
is_persistent_connection = false
}

      This rule has all POST commands being handled by the common_handler procedure in myrule.mtcl. That procedure can then do any pattern matching necessary.

    Back to Top

  8. Compatibility

    9. Click here for the compatibility document. If you get an error, you need to download the optional update package with the Update Wizard.

    Back to Top
    << Previous Section    Next Section >>