Deprecated: Use web_custom_request.

Allows you to create a custom HTTP request with any method supported by HTTP.

Example: flex_web_request Alphabetical Listing of Flex Functions (FLEX)
int flex_web_request( const char *RequestName, <List of Attributes>,  LAST ); 

This function returns LR_PASS (0) on success or LR_FAIL (1) on failure. Note that LR_PASS and LR_FAIL generally indicate whether the function call completed without an exception, and not that the test step succeeded.

All input string arguments (char type) except the step name can be parameterized using standard parameterization.


Name Comments
RequestName The name of the step, as it appears in the graphical script.
List of Attributes

See Attributes Table.

Note: Attribute names are case–sensitive (Method vs. method).

EXTRARES A demarcation parameter indicating that the next parameter will be a list of resource attributes.
List of Resource Attributes See List of Resource Attributes.
LAST A marker that indicates the end of the argument list.

General Information

The flex_web_request function is an Action Functions function that allows you to create a custom HTTP request using any method or body. By default, VuGen generates this function only for requests that could not be interpreted with other functions. The request can be a standard HTTP request (such as SOAP) or a binary request (such as an externalizable object, or any request being processed with the Try to encode externalizable object code generation option disabled).

To insert this function manually, use the Add Step dialog box. To specify an HTTP header to be sent before the custom request, add a web_add_header or web_add_auto_header function.

Attributes Table

URL The URL (Uniform Resource Locator) of the web page to load.
Method The form submission method: POST or GET.
TargetFrame The name of the frame containing the current link or resource. Click here for more information.

The type of encoding method used. EncType specifies a Content–Type, such as "text/html", to be specified as the value of the "Content–Type" REQUEST header for the current replay. flex_web_request performs no body encoding.

The Body argument specifies the body to be used as is (or after applying "Binary" processing), with any encoding having already been applied. Therefore, specifying an EncType that does not match the body may cause a server–side error.

In general, it is recommended that you do not edit the EncType as recorded. Any EncType specification silently overrides any web_add_[auto_]header for Content–Type.

If "EncType=" (empty value) is specified, no "Content–Type" request header is generated.

If "EncType" is omitted, any applicable web_add_[auto_]header is used.

If there is no header and "Method=POST", "application/x–www–form–urlencoded" is used as a default. Otherwise, no Content–Type request header is generated.


The content–type of RESPONSE header during recording e.g., text/html, application/x–javascript. It is read to determine whether the target URL is a recordable resource. Click here for more information.

RecContentType specifies the "Content–Type" RESPONSE header value as recorded. The RecContentType value is used when Resource is not specified for determining whether the target URL is a resource or not.

Referer The referring web page. The page that referred to the current page. If the location was explicitly expressed, this attribute is omitted.
Body The body of the request. See the Body Attribute section for a complete list of available options.
Raw Body The body of the request is passed as a pointer to the data. See the Raw Body Attribute section.
BodyFilePath The path to a file to be passed as the body of the request. BodyFilePath cannot be used together with Body, or any Body Attribute or Raw Body Attribute: BodyBinary, BodyUnicode, RAW_BODY_START , or Binary=1.

A value indicating whether the URL is a resource:"Resource=1" indicates that the URL is a resource, which implies that it is not critical for the success of the script.

Any failures in downloading the resource will be considered as warnings rather than errors

Whether to download it or not is affected by the "Download non–HTML resources" Run–Time Setting The response is not parsed as HTML "Resource=0" indicates the URL is critical, not affected by the RTS, and will be parsed if required.

ResourceByteLimit See the ResourceByteLimit section.
Snapshot The file name of the snapshot file (inf extension), used for correlation.
Mode the Recording Level: HTML or HTTP. Click here for more information.

The base URL for resolving relative URLs within the EXTRARES group.URLs can be absolute (like "http://weather.abc.com/weather/forecast.jsp?locCode=LFPO") or relative (like "forecast.jsp?locCode=LFPO").

The actual downloading of URLs is always performed using absolute URLs, so that relative URLs must be resolved using another (absolute) URL as a "base".

For example, resolving the relative "forecast.jsp?locCode=LFPO" using "http://weather.abc.com/weather/" as a base will yield "http://weather.abc.com/weather/forecast.jsp?locCode=LFPO". By default, when "ExtraResBaseDir" is not specified, the primary URL of the function is used.


"User–Agent" is the name of an HTTP header identifying the application, usually a browser, which represents the user in the interaction with the server. For example, the header "User-Agent: Mozilla/5.0 (Windows NT 10.0; Trident/7.0; rv:11.0) like Gecko" identifies Microsoft Internet Explorer 11.0 for Windows NT 10.

Other User–Agent strings are used for different browsers and for other, non–browser applications. Usually, all requests from an application use the same User–Agent value, which the recorder specifies as a runtime setting. However, even within a regular browser session, there may be non–browser components (for example, Active–X) that interact with a server directly, and usually have a different User–Agent string than the browser. Specifying a User-Agent indicates that this is such a non–browser request.

The specified string is used in the "User–Agent:" HTTP header, and affects the replay behavior, for example, by not using the browser cache, assuming the specified URLs are resources, etc. No check is made to verify that the specified value is different than that of the browser.

Binary "Binary=1" specifies that each sequence in the Body of the form \\x##, where "##" are two "hexadecimal digits" (0–9, a–f or A–F), be replaced by a single byte containing the specified hexadecimal value. If "Binary=0" (the default), such sequences are passed literally. Note that two backslashes are used. They are interpreted as one backslash by to the C interpreter. When a zero byte is NOT required, one backslash can be used without "Binary=1" (e.g., \x20 instead of \\x20). When a zero byte IS required, specifying \x00 would cause the string to be logically truncated (null terminator), and \\x00 needs to be specified using "Binary=1".
ContentEncoding Requests that the request body by encoded (e.g., compressed) using the specified method (i.e., gzip or deflate), and that the corresponding "Content–Encoding:" HTTP header be sent along with the request.

Using Binary Code

You can use the following format to include binary code in the Body parameter of a flex_web_request function:


This represents the hexadecimal value that is represented by [char1][char2].

For example: \x24 is 16*2+4=36, which is a $ sign; \x2B is + sign.

Sequences that do not represent valid 2–character hexadecimal sequences are treated by VuGen as ASCII text. Do not use 1–character hexadecimal sequences. For example, "\x2" is not a valid 2–character hexadecimal sequence. Use "\x02", instead.

Note that binary values appear in a script as \\x, i.e., the "x" is preceded by two backslashes. This is due to C language escaping laws. However, when generating a flex_web_request function by using VuGen, you need to type only one backslash.

If you use parameterization within a flex_web_request function, include only one backslash within the definition of the parameter. This is because parameter substitution does not perform any C escaping conversion.

The HTTP header can be modified to pass additional information about the request to the server. Using HTTP headers you can, for example, allow other content types in the response such as compressed files, or you can request a web page only on certain conditions. To modify the HTTP header in the request, see web_add_header. To modify all subsequent requests, see web_add_auto_header.