Configuring HTTP Locations

The HTTP Locations table lets you configure up to 120 for greater than 8 GB and 40 for less than 8 GB HTTP Locations. Locations are specified for each HTTP proxy server to map the incoming requests received by that server. Mapping is based on matching the URL in the request. Each location specifies the URL prefix or pattern to match and the target Upstream Group to which the request is to be forwarded to.

The HTTP Locations table is a "child" of the HTTP Proxy Servers table (see Configuring HTTP Proxy Servers), reflecting the nesting of Location contexts within Server contexts in the NGINX configuration file. This may be used to specify unique handling of URLs by file type (using a regex pattern) or by pathname (using a Prefix or Exact Match pattern).

The following procedure describes how to configure HTTP Locations through the Web interface. You can also configure it through ini file [HTTPLocation] or CLI (configure network > http-proxy > location).

➢ To configure an HTTP Location:
1. Enable the HTTP Proxy application, as described in Enabling the HTTP Proxy Application.
2. Open the HTTP Proxy Servers table (Setup menu > IP Network tab > HTTP Proxy folder > HTTP Proxy Servers).
3. In the table, select the required HTTP Proxy Server, and then click the HTTP Locations link located below the table; the HTTP Locations table appears.
4. Click New; the following dialog box appears:

5. Configure an HTTP Location according to the parameters described in the table below.
6. Click Apply, and then save your settings to flash memory.

HTTP Locations Table Parameter Descriptions

Parameter

Description
General  

'Index'

[Index]

Defines an index number for the new table row.

Note:

■ Each row must be configured with a unique index.
■ The parameter is mandatory.

'URL Pattern'

url-pattern

[URLPattern]

Defines the URL pattern. Received GET or POST requests are matched against the locations in the HTTP Locations table by matching the URL in the received request to the URL configured by this parameter. If there is a match, the prefix is stripped from the request and then forwarded in the outgoing HTTP request.

Note:

■ The pattern must be based on the pattern type configured in the 'URL Pattern Type' parameter (see below).
■ The NGINX directive for this parameter is "location modifier pattern".

'URL Pattern Type'

url-pattern-type

[URLPatternType]

Defines the type of URL pattern used for configuring the 'URL Pattern' parameter (see above).

■ [0] Prefix = For Example, "/" matches any URL beginning with a forward slash "/". For NGINX, this option has no modifier.
■ [1] Exact = Defines an exact pattern to match, for example, "/abc/def" matches only the file "/abc/def". For NGINX, this option is specified using the "=" modifier.
■ [2] Regex = Regex-based pattern (case sensitive), for example, "/files/*.img" matches all files ending in .img in the directory /files. For NGINX, this option is specified using the "~" modifier.
■ [3] Case-Insensitive Regex = Regex-based pattern that is case-insensitive, for example, "*.img" matches abc.IMG as well as xyz.img. For NGINX, this option is specified using the "~*" modifier.
■ [4] Prefix Ignore Regex = For NGINX, this option is specified using the "^~" modifier.

For example, assume that you have configured the following URL patterns for four HTTP Locations:

■ 1) /files – Prefix pattern type
■ 2) /files/phone – Prefix pattern type
■ 3) /files/firmware -- Prefix-Ignore-Regex pattern type
■ 4) *.jpg – Regex pattern type

Therefore, the request URL "/files/phone/aaa" matches Location 2 and the request URL "/files/phone/logo.jpg" matches Location 4. The request URL "/files/firmware/logo.jpg" matches Location 3 (and not Location 4).

Note: The NGINX directive for this parameter is "location modifier pattern". For more information on NGINX modifiers, see ngx_http_core_module.html.

'Upstream Scheme'

upstream-scheme

[UpstreamScheme]

Defines the protocol for sending requests to the Upstream Group.

■ [0] HTTP (default)
■ [1] HTTPS

Note: The NGINX directive for this parameter is "proxy_pass scheme://upstream".

'Upstream Group'

upstream-group

[UpstreamGroup]

Assigns a group of servers (Upstream Group) to handle the HTTP requests. To configure Upstream Groups, see Configuring Upstream Groups.

Note: The NGINX directive for this parameter is "proxy_pass scheme://upstream".

'Upstream Path'

upstream-path

[UpstreamPath]

Defines a path to prepend to the URL before sending the request to the Upstream Group.

Note: The NGINX directive for this parameter is "proxy_pass scheme://upstream/path".

'Outbound Interface'

outbound-intfc

[OutboundInterface]

Assigns a local, IP network interface for sending requests to the Upstream Group. To configure IP network interfaces, see Configuring IP Network Interfaces.

By default, no value is defined.

Note:

■ The parameter is mandatory.
■ The NGINX directive for this parameter is "proxy_bind".

'Additional Directive Set'

directive-set

[AdditionalDirectiveSet]

Assigns an NGINX directive set for the HTTP location. To configure NGINX directives, see Configuring HTTP Directive Sets.

'Cache'

cache

[Cache]

Enables the caching of files in this location.

■ [0] No
■ [1] Yes (default)

Note:

■ Currently, this feature is not supported.
■ The NGINX directive for this parameter is "proxy_cache zone|off".

SSL

'TLS Context'

tls-context

[TLSContext]

Assigns a TLS Context for the TLS connection with the HTTP location.

To configure TLS Contexts, see Configuring TLS Certificates.

Note:

■ The parameter is applicable only if the connection protocol is HTTPS (configured in the 'Upstream Scheme' parameter, above).
■ The NGINX directives for this parameter are "proxy_ssl_certificate", "proxy_ssl_certificate_key", "proxy_ssl_ciphers", "proxy_ssl_protocols", and "proxy_ssl_password_file".

'Verify Certificate'

verify-cert

[VerifyCertificate]

Enables TLS certificate verification when the connection with the location is based on HTTPS. It verifies the certificate of the incoming connection request from the Upstream Group.

■ [0] No = (Default) No certificate verification is done.
■ [1] Yes = The device verifies the authentication of the certificate received from the HTTPS location. The device authenticates the certificate against the trusted root certificate store associated with the assigned TLS Context (see 'TLS Context' parameter above) and if ok, allows communication with the HTTPS location. If authentication fails, the device denies communication (i.e., handshake fails). The device can also authenticate the certificate by querying with an Online Certificate Status Protocol (OCSP) server whether the certificate has been revoked. This is also configured for the associated TLS Context.

Note:

■ The parameter is applicable only if the connection protocol is HTTPS (configured in the 'Upstream Scheme' parameter, above).
■ The NGINX directive for this parameter is "proxy_ssl_verify".