Applies To:

Show Versions Show Versions

Manual Chapter: Configuration Guide for the BIG-IP® Link Controller: Managing HTTP and FTP Traffic
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


21

Managing HTTP and FTP Traffic


Introducing HTTP and FTP traffic management

The Link Controller offers several features that you can use to intelligently control your HTTP, HTTPS, and FTP traffic. Examples of these features are the insertion of headers into HTTP requests, and the compression of HTTP server responses.

Some of these features are available through configuration of an HTTP or an FTP profile. A profile is a group of settings, with values, that corresponds to a specific type of traffic, such as HTTP traffic. A profile defines the way that you want the Link Controller to manage that traffic type.

In addition to HTTP and FTP profiles, the Link Controller includes other features to help you manage your application traffic, such as health monitors for checking the health of HTTP and FTP services, and iRulesTM for querying or manipulating HTTP header or content data.

Table 21.1 summarizes the capabilities within the Link Controller for managing HTTP and FTP traffic and shows the system object that you use to configure each feature.

Table 21.1 Summary of the Link Controller features related to HTTP and FTP traffic control
Feature
Description
Configuration Object
HTTP compression
You can create an HTTP profile that causes the Link Controller to compress server responses using well-defined algorithms such as gzip and deflate.
HTTP profile
Monitoring of HTTP, HTTPS, and FTP ports on pool members
You can associate an HTTP, HTTPS, or FTP monitor with the members of a pool to ensure that pool members are ready and able to receive traffic on specific ports.
Load balancing pool

HTTP, HTTPS, and FTP health monitors
Chunking of requests and responses
You can configure the Link Controller to unchunk or rechunk HTTP responses.
HTTP profile
Pipelining
The system supports HTTP pipelining.
HTTP profile
IPV4-to-IPV6 compatibility
Ensures compatibility between IP version 4 and IP version 6 clients and servers when using the FTP protocol.
FTP profile

Configuring the properties of an HTTP profile

You can configure HTTP profile settings to ensure that HTTP traffic management suits your specific needs. These configuration settings are organized into three categories on the New HTTP Profile screen in the Configuration utility: General Properties, Settings, and Compression. You can configure these settings when you create a profile, or after profile creation by modifying the profile's settings. For specific procedures on configuring a profile, see Chapter 16, Understanding Profiles .

Table 21.2 shows the general properties, namely a name and a parent profile, that you can specify for a custom HTTP profile. Following this table are descriptions of these general properties. For information about HTTP profile settings, see Configuring HTTP profile settings , and for information on compression settings, see Configuring HTTP compression settings

Table 21.2 General properties of an HTTP profile
General property
Description
Default Value
Name
Specifies the user-supplied name of the profile. You must specify a name for your profile.
No default value
Parent Profile
Specifies the profile from which your custom profile is derived.
http

Before configuring an HTTP profile, it is helpful to have a description of its general properties.

Specifying a profile name

To create an HTTP profile, you must specify a unique name for the profile. The Name setting is one of only two settings for which you must actively specify a value when creating an HTTP profile; all other settings have default values.

To specify a profile name, simply locate the Name setting and type a unique name for the profile.

Specifying a parent profile

Every profile that you create is derived from a parent profile. You can use the default http profile as the parent profile, or you can use another HTTP profile that you have already created.

To specify a parent profile, locate the Parent Profile setting and select a profile name.

Configuring HTTP profile settings

For the profile settings that appear in the Settings section of the HTTP Profile screen, you can specify values where none exist, or modify any default values to suit your needs. For information about other HTTP profile settings, see Configuring the properties of an HTTP profile and Configuring HTTP compression settings .

Table 21.3 shows these profile settings. For those settings that have default values, you can retain those default settings or modify them. Following this table are descriptions of the settings and the procedure for changing them.

Table 21.3 Configuration settings in an HTTP profile
Setting
Description
Default Value
Basic Auth Realm
Specifies an authentication realm for client authentication.
No default value
Fallback Host
Specifies the fallback host to send as an HTTP 302 response when all nodes are down.
No default value
Header Insert
Specifies the header string that you want to insert into an HTTP request.
No default value
Header Erase
Specifies the header string that you want to erase from an HTTP request.
No default value
Response Chunking
Specifies how to handle chunking for HTTP responses. Possible values are Unchunk, Rechunk, Selective, and Preserve.
Preserve
Redirect Rewrite
Allows you to modify HTTP redirections. Possible values are Matching, All, Nodes, or None.
None
Maximum Header Size
Specifies the maximum size that the Link Controller allows for HTTP headers. The default value is represented in bytes.
16
Pipelining
Enables or disables HTTP pipelining.
Disabled
LWS Maximum Columns
Specifies the maximum width allowed for an HTTP header that is inserted into an HTTP request.
80
LWS Separator
Specifies the separator that the Link Controller should use between HTTP headers when a header exceeds the maximum width allowed.
\r\n
Pipelining
Enables or disables HTTP pipelining, a feature of HTTP version 1.1.
Disabled

Before configuring an HTTP profile, it is helpful to have a description of certain settings that you might want to change.

Specifying a realm for basic authentication

The value of the Basic Auth Realm setting is a string that you provide. The Link Controller sends this string to a client as part of client authentication.

To configure this setting, locate the Basic Auth Realm setting and type a value.

Specifying a fallback host

Another feature that you can configure within an HTTP profile is HTTP redirection. HTTP redirection allows you to redirect HTTP traffic to another protocol identifier, host name, port number, or URI path. For example, if all members of the targeted pool are unavailable (that is, the members are disabled, marked as down, or have exceeded their connection limit), the Link Controller can redirect the HTTP request to the fallback host, with the HTTP reply Status Code 302 Found.

When configuring the Link Controller to redirect HTTP traffic to a fallback host, you can specify an IP address or a fully-qualified domain name (FQDN). The value that you specify becomes the value of the Location header that the servers sends in the response. For example, you can specify a redirection as http://redirector.siterequest.com.

Inserting headers into HTTP requests

An optional setting in an HTTP profile is HTTP header insertion. The HTTP header being inserted can include a client IP address. Including a client IP address in an HTTP header is useful when a connection goes through a secure network address translation (SNAT) and you need to preserve the original client IP address.

The format of the header insertion that you specify is generally a quoted string. Alternatively, however, you can insert a Tools Command Language (TCL) expression into a header that dynamically resolves to the desired value. When you assign the configured HTTP profile to a virtual server, the Link Controller then inserts the header specified in the profile into any HTTP request that the Link Controller sends to a pool or pool member.

To insert a header into an HTTP request, locate the Header Insert setting and type a value.

Erasing content from HTTP headers

Another optional setting is the header erase setting. Using this setting, you can configure a pool to erase the contents of a header from an HTTP client request. When you use this setting, the Link Controller erases the contents of the specified header and replaces that content with blank spaces. The header itself is retained.

With this feature, you can erase header content from HTTP requests before forwarding the requests over the network. Such headers might contain sensitive information, such as user IDs or telephone numbers, that must be erased before the information is forwarded.

The client header with the contents to be erased must be specified as a quoted string.

To erase a header from an HTTP request, locate the Header Erase setting and type a value.

Configuring chunking

Sometimes, you might want to inspect and/or modify HTTP application data, such as when you are using an iRule that inspects the content of an HTTP response. Such inspections or modifications require that the response be unchunked, that is, not in chunked encoding. Using the Response Chunking settings, the Link Controller can unchunk a chunked response before performing an action on that response.

Possible values for this setting are Unchunk, Rechunk, Selective, and Preserve. The default value is Preserve.

Table 21.4 describes each of these values and the action that the Link Controller takes, depending on whether an original response is chunked or unchunked.

Table 21.4 Chunking behavior of the Link Controller
Setting
Original response is chunked
Original response is unchunked
Unchunk
The Link Controller unchunks the response and processes the HTTP content, and passes the response on as unchunked. The connection closes when all data is sent to the client as indicated by the Connection: Close header.
The Link Controller processes the HTTP content and passes the response on untouched.
Rechunk
The Link Controller unchunks the response, processes the HTTP content, re-adds the chunk trailer headers, and then passes the response on as chunked. Any chunk extensions are lost.
The Link Controller adds transfer encoding and chunking headers on egress.
Selective
Same as Rechunk.
The Link Controller processes the HTTP content and then passes the response on untouched.
Preserve
The Link Controller leaves the response chunked, processes the HTTP content, and passes the response on untouched. Note that if HTTP compression is enabled, the Link Controller does not compress the response.
The Link Controller processes the HTTP content and then passes the response on untouched.

Rewriting an HTTP redirection

Sometimes, a client request is redirected from the HTTPS protocol to the HTTP protocol, which is a non-secure channel. If you want to ensure that the request remains on a secure channel, you can cause that redirection to be rewritten so that it is redirected back to the HTTPS protocol.

Note that the rewriting of any redirection takes place only in the HTTP Location header of the redirection response, and not in any content of the redirection.

To enable the Link Controller to rewrite HTTP redirections, you simply specify, through the Configuration utility, the way that you want the system to handle URIs during the rewrite. Once enabled, this feature rewrites the protocol name port number

Possible values for this setting are Matching, All, Nodes, or None.

Selecting URIs to rewrite

When configuring the Link Controller to rewrite HTTP redirections, you specify whether the system should rewrite only those URIs matching the URI originally requested by the client (minus an optional trailing slash), or whether the system should rewrite all URIs. In the latter case, the system always rewrites redirected-to URIs, and rewrites those URIs as if they matched the originally-requested URIs.

If the URI contains a node IP address instead of a host name, you can configure the Link Controller to change that IP address to the virtual server address.

Table 21.5 shows examples of how redirections of client requests are transformed when the Link Controller is listening on port 443, and the Rewrite Redirections setting is enabled.

Table 21.5 Examples of rewriting HTTP redirections with the system listening on port 443
Original Redirection
Rewrite of Redirection
http://www.myweb.com/myapp/
https://www.myweb.com/myapp/
http://www.myweb.com:8080/myapp/
https://www.myweb.com/myapp/

Table 21.6 shows examples of how redirections of client requests are transformed when the SSL proxy is listening on port 4443, and the rewrite feature is enabled.

Table 21.6 Examples of rewriting HTTP redirections with the system listening on port 4443
Original Redirection
Rewrite of Redirection
http://www.myweb.com/myapp/
https://www.myweb.com:4443/myapp/
http://www.myweb.com:8080/myapp/
https://www.myweb.com:4443/myapp/

Rewriting the protocol name

When configured to rewrite HTTP redirections, the Link Controller rewrites the HTTP protocol name to HTTPS. For example, a client might send a request to https://www.sample.com/bar and be initially redirected to http://www.sample.com/bar/, which is a non-secure channel. If you want the client request to remain on a secure channel, you can configure the Link Controller to rewrite the redirected URI to go to https://www.sample.com/bar/ instead. (Note the addition of the trailing slash.)

Specifying the maximum header size

With this setting, you can specify the maximum size that the Link Controller allows for HTTP headers. The default value is 16 and is represented in bytes.

Enabling support for pipelining

Normally, a client cannot make a request until the previous request has received a response. HTTP/1.1 pipelining allows clients to make requests even when prior requests have not received a response. For this to succeed, however, destination servers must include support for pipelining. This feature enables that support on the Link Controller.

To enable pipelining, locate the Pipelining setting and check the box. By default, this feature is set to Disabled.

Inserting an XForwarded For header

When using connection pooling, which allows clients to make use of existing server-side connections, you can insert the XForwarded For header and specify a client IP address. When you configure the Link Controller to insert this header, the target server can identify the request as coming from a client other than the client that initiated the connection.

Configuring the maximum columns for linear white space

This setting specifies the maximum number of columns allowed for a header that is inserted into an HTTP request.

To configure the LWS Maximum Columns setting, specify a maximum value.

Configuring a linear white space separator

This setting specifies the separator that the Link Controller should use between HTTP headers when a header exceeds the maximum width specified by the LWS Maximum Columns setting.

To configure the LWS Separator setting, specify a value for the separator.

Configuring HTTP compression settings

In a typical client-server scenario, browsers and servers can be configured to compress and uncompress HTTP content. HTTP compression reduces the amount of data to be transmitted, thereby significantly reducing bandwidth usage. The following two sections describe the benefits of configuring the Link Controller to perform HTTP compression tasks.

Compression in a typical client-server scenario

When HTTP compression is enabled in a client-server environment, a browser inserts an Accept-Encoding header into a client request, specifying the compression methods that the browser understands. Consequently, the server reads the header and compresses the response body with one of those compression methods. The server then inserts a Content-Encoding header in the response, to communicate to the browser the compression method that the server used. Upon receiving the compressed response, the browser reads the Content-Encoding header and uncompresses the data accordingly.

Enabling HTTP compression without an Link Controller typically requires installation and configuration of compression software on the destination server.

Compression using the Link Controller

An optional feature is the Link Controller's ability to off-load HTTP compression tasks from the target server. All of the tasks needed to configure HTTP compression on the Link Controller, as well as the compression software itself, are centralized on the Link Controller.

The primary way to enable the HTTP compression option is by setting the Compression setting of an HTTP profile to Enabled. This causes the Link Controller to compress HTTP content for any responses matching the values that you specify in the Request-URI or Content-Type settings of the HTTP profile.

If you want to enable HTTP compression for specific connections, you can write an iRule that specifies the HTTP:compress enable command. For more information, see Chapter 17, Writing iRules .

When HTTP compression is enabled on the Link Controller, the Link Controller executes a series of steps:

  1. First, the Link Controller reads the Accept-Encoding header of a client request, looks for specification of either the deflate or gzip compression method, and notes whether either method is marked as being preferred.
  2. If the Keep Accept Encoding setting in the HTTP profile is set to Disabled, the Link Controller then removes the Accept-Encoding header from the request and passes the request on to the server. Removing the Accept-Encoding header prevents the server from performing the HTTP compression and from inserting the Content-Encoding header into its response.
  3. Upon receiving the server response, the Link Controller inserts the Content-Encoding header, specifying the compression method that it has chosen to use. The Link Controller chooses a compression method by looking for the specification of either the gzip or deflate compression method in the Accept-Encoding header of the client request. If the client request does not specify a compression method, the Link Controller uses the deflate method to compress the response data.
  4. Finally, the Link Controller then compresses the response and sends it to the client. The client then reads the Content-Encoding header in the response, determines the compression method used, and uncompresses the data accordingly.

Using the Link Controller HTTP compression feature, you can include or exclude certain types of URIs or files that you specify. This is useful because some URI or file types might already be compressed. Using CPU resources to compress already-compressed data is not recommended because the cost of compressing the data usually outweighs the benefits. Examples of regular expressions that you might want to specify for exclusion are.*.pdf or.*.gif.

Table 21.7 shows the compression settings that you can specify within an HTTP profile. Configuring these settings means either specifying a value where no default value exists, or changing a default value.

Table 21.7 Configurable settings for HTTP compression
Setting
Description
Default Value
Compression
Enables or disables the HTTP compression feature.
Disable
URI Compression
Displays the settings for including or excluding certain Request-URI responses. Possible values are URI List or Not Configured.
Not Configured
URI List
If the URI Compression setting is set to Enabled, specifies the URI targeted for compression, as well as the types of responses to include for and exclude from URI compression.
No default value
Content Compression
Displays the settings for including or excluding certain Content-Type responses. Possible values are Content List or Not Configured.
Not Configured
Content List
If the Content Compression setting is set to Enabled, specifies the type of content targeted for compression, as well as the type of responses to include for or exclude from content compression.
In the Include List box, default values are:
text/
application/(xml|x-javascript)
Minimum Content Length
Specifies the minimum length in bytes of a server response that is acceptable for compressing that response. The length in bytes applies to content length only, not headers.
1024
Compression Buffer Size
Specifies the maximum number of compressed bytes that the Link Controller buffers before deciding whether or not to insert a Content-Length header into the response that specifies the compressed size.
4096
gzip Memory Level
Specifies the number of kilobytes of memory that the Link Controller uses for internal compression buffers when compressing a server response.
8
gzip Window Size
Specifies the number of kilobytes in the window size that the Link Controller uses when compressing a server response.
16
gzip Level
Specifies the amount and rate of compression.
1
Vary Header
Enables or disables the insertion of a Vary header into cacheable server responses.
Enabled
HTTP/1.0 Requests
Enables or disables compression of responses to HTTP/1.0 client requests.
Disabled
Keep Accept Encoding
When enabled, allows the target server to perform the HTTP compression instead of the Link Controller.
Disabled

Before configuring an HTTP profile, it is helpful to have a description of the compression settings that you might want to change.

Enabling or disabling the compression feature

The Compression setting causes the Link Controller to perform compression on server responses. Possible values are:

  • Enabled
    This value causes the Link Controller to compress, or refrain from compressing, HTTP server content for any responses matching the values that you specify in the URI List or Content List settings of the HTTP profile.
  • Disabled
    When the Compression setting is set to Disabled, the Link Controller does not perform HTTP compression.
  • Selective
    This setting causes the Link Controller to perform HTTP compression only when specified by an iRule containing the HTTP::compress command.

To enable HTTP compression, locate the Compression setting and select Enabled. If you are enabling compression through the use of the iRule command HTTP::compress <enable>, select Selective.

Using URI compression

If you enable compression, you probably do not want the Link Controller to compress every kind of server response. Using the URI Compression setting, you can set its value to URI List, which instructs the Link Controller to include in compression, or exclude from compression, certain responses that are specified in the URIs of client requests.

More specifically, you can type regular expressions to specify the types of server responses that you want the Link Controller to include in, or exclude from, compression. For example, you can specify that you want the Link Controller to compress all .htm responses by typing the regular expression .*.htm. The Link Controller then compares that response type to the URI specified within each client request, and if the system finds a match, takes some action.

Any regular expression that you specify must be in Advanced Regular Expression (ARE) syntax.

To use the URI Compression feature, locate the URI Compression setting and select URI List. You can then use the Include List box or the Exclude List box to type your regular expressions. If you do not specify any list (either URI or content), the Link Controller compresses all responses. For more information on content lists, see Using content compression .

Including URI-specified responses in HTTP compression

When URI compression setting is enabled, and you type one or more values in the Include List box, the Link Controller compresses only those responses that match the URI part of the client request line.

The values you specify in the Include List box are in the form of regular expressions. For example, if the Include List box contains the values .*.txt, .*.htm, and .*.html, and those expressions match URIs in client requests, then the Link Controller compresses only the responses for those URIs that match the specified regular expressions.

To apply this setting successfully, the Link Controller must find a match in at least one of the values specified in the Include List box. If the Link Controller finds no match, then no response is compressed.

Excluding URI-specified responses in HTTP compression

When the URI compression setting is enabled, and you type one or more values in the Exclude List box, the Link Controller excludes from compression those responses that match the URI part of the client request line.

The values you specify in the Exclude List box are in the form of regular expressions. For example, if the Exclude List box contains the value .*.pdf, and that expression matches URIs in client requests, then the Link Controller excludes from compression any .pdf responses for those URIs.

To apply this setting successfully, the Link Controller must find a match in at least one of the values specified in the Exclude List box. If the Link Controller finds no match, then no responses are excluded from compression.

Using content compression

If you enable compression, you probably do not want the Link Controller to compress every kind of server response. Using the Content Compression setting, you can set its value to Content List, which instructs the Link Controller to include in compression, or exclude from compression, certain responses that are specified in the Content-Type header of server responses.

More specifically, you can type regular expressions to specify the types of server responses that you want the Link Controller to include in, or exclude from, compression. For example, you can specify that you want the Link Controller to compress all .htm responses by typing the regular expression .*.htm. The Link Controller then compares that response type to the value of the Content-Type header specified within each server response, and if the system finds a match, takes some action.

Any regular expression that you specify must be in Advanced Regular Expression (ARE) syntax.

To use the Content Compression feature, locate the Content Compression setting and select Content List. You can then use the Include List box or the Exclude List box to type your regular expressions. If you do not specify any list (either URI or content), the Link Controller compresses all responses. For more information on content lists, see Using URI compression .

Including Content-Type responses in HTTP compression

When compression is enabled and you specify one or more values in the Include List box, the Link Controller includes only those responses that match the value of the server's Content-Type header. The value of this setting is a list of those header values. For example, if the Include List box contains the values application/pdf and image/**, then only responses of those content types are compressed.

To include all text types, you assign the value text/.* to this setting.

Excluding Content-Type responses in HTTP compression

When compression is enabled and you specify one or more values in the Exclude List box, the Link Controller excludes those responses that match the value of the server's Content-Type header. The value of this setting is a list of those header values. For example, if the Exclude List box contains the values application/pdf and image/**, then responses of those content types are excluded from compression.

To exclude all text types, you assign the value text/.* to this setting.

Specifying minimum content length for compression

When compression is enabled, the Minimum Content Length setting specifies the minimum length of a server response in uncompressed bytes that the Link Controller requires for compressing that response. The Link Controller finds the content length of a server response in the Content-Length header of the server response. Thus, if the content length specified in the response header is below the value assigned to the Minimum Content Length setting, the Link Controller does not compress the response. The length in bytes applies to content length only, not headers.

For example, using the default value of 1024, the Link Controller compresses only those responses with HTTP content containing at least 1024 bytes.

Sometimes the Content-Length header does not indicate the content length of the response. In such cases, the Link Controller compresses the response, regardless of size.

To specify a minimum content length, locate the Minimum Content Length setting, and type a numeric value.

Specifying the compression buffer size

When compression is enabled, the Compression Buffer Size setting specifies the maximum number of compressed bytes that the Link Controller buffers before deciding whether or not to preserve a Keep-Alive connection and rewrite the Content-Length header.

For example, using the default value of 4096, the Link Controller buffers up to 4096 bytes of compressed data before deciding whether or not to preserve the connection and rewrite the Content-Length header.

The Link Controller's decision to rewrite the Content-Length header depends on whether response chunking is enabled (using the Response Chunking profile setting). Table 21.8 shows the behavior of the Link Controller with respect to compression buffer size and response chunking.

Table 21.8 Link Controller behavior based on maximum buffer size
If the size of the compressed response is
And the compressed response is
Then the Link Controller
Equal to or greater than the maximum buffer size
Chunked
Keeps the connection open (if the Connection header is not set to Close).
Not chunked
Closes the connection by changing the value of the Connection header to Close.
Less than the maximum buffer size
Chunked
Does not insert a Content-Length header with a compressed response size.
Not chunked
Inserts a Content-Length header with a compressed response size.

For more information, see Specifying minimum content length for compression , preceding.

To specify a compression buffer size, locate the Compression Buffer Size setting and type a numeric value.

Specifying a memory level for gzip compression

The gzip Memory Level setting specifies a value representing the amount of kilobytes of memory that the Link Controller uses to compress data when using the gzip or deflate compression method. The value of the gzip Memory Level setting must be a power-of-2 integer, in bytes, ranging from 1 to 256.

Generally, a higher value causes the Link Controller to use more memory, but results in a faster and higher compression ratio. Conversely, a lower value causes the Link Controller to use less memory, but results in a slower and lower compression ratio. The default value is 8.

To specify a memory level, locate the gzip Memory Level setting and select a numeric value.

Specifying window size for gzip compression

The gzip Window Size setting specifies a value representing the number of kilobytes in window size that the Link Controller uses when compressing a server response using the gzip or deflate compression method. The value of the gzip Window Size setting must be a power-of-2 integer, in bytes, ranging from 1 to 128.

Generally, a higher value causes the Link Controller to use more memory, but results in a higher compression ratio. Conversely, a lower value causes the Link Controller to use less memory, but results in a lower compression ratio. The default value is 16.

To specify a window size, locate the gzip Window Size setting and select a numeric value.

Specifying a compression level

Using the gzip Level setting, you can specify the extent to which data is compressed, as well as the compression rate. When specifying a compression level, the following principles apply:

  • Specify a higher level causes data to be more compressed but at a slower rate.
  • Specify a lower level causes data to be less compressed but at a higher rate.

An allowed value is any whole number ranging from 1 through 9. The default compression level is 1.

Enabling or disabling the Vary header

When compression is enabled, the Vary Header setting inserts the Vary: Accept-Encoding header into a compressed server response. If the Vary header already exists in the response, the Link Controller appends the value Accept-Encoding to that header.

The reason for inserting the Vary: Accept-Encoding header into a server response is to follow a recommendation by RFC2616, which states that the Vary header should be inserted into any cacheable response that is subject to server-driven negotiation. Server responses that are subject to HTTP compression fall into this category.

If the Vary Header setting is disabled, the Link Controller does not insert the Vary header into a server response.

To disable the Vary header, locate the Vary Header setting and clear the Enabled box.

Allowing compression for HTTP/1.0 requests

The HTTP/1.0 Requests setting is included for backward compatibility, allowing HTTP compression for responses to HTTP/1.0 client requests. The default value for this setting is Disabled.

If this setting is set to Enabled, the Link Controller only compresses responses in either of the following cases:

  • When the server responds with a Connection: close header
  • When the response content is no greater than the value of the Compression Buffer Size setting

To enable compression for HTTP/1.0 requests, locate the HTTP/1.0 Requests setting and check the box.

Keeping the Accept-Encoding header

Normally, when you enable HTTP compression, the Link Controller strips out the Accept-Encoding header from the HTTP request. This causes the Link Controller to perform the HTTP compression instead of the target server.

By default, the Keep Accept Encoding setting is disabled. If you want to allow the target server instead of the Link Controller to perform the HTTP compression, simply enable this setting.

Configuring FTP profile settings

You can tailor FTP profile settings to your specific needs. For those settings that have default values, you can retain those default settings or modify them. You can modify any settings either when you create the profile, or at any time after you have created it. For specific procedures on configuring a profile, see Chapter 16, Understanding Profiles .

Table 21.9 lists these configurable settings, along with a short description of each and the default values. Following this table are descriptions of specific settings.

Table 21.9 Settings of an FTP profile
General property
Description
Default Value
Name
Specifies the user-supplied name of the profile. Specifying a name for your profile is required.
No default value
Parent Profile
Specifies the profile from which your custom profile is derived.
FTP
Translate Extended
Ensures compatibility between IP version 4 and IP version 6 clients and servers when using the FTP protocol.
Enabled
Data Port
Allows the FTP service to run on an alternate port.
20

Before configuring an FTP profile, it is helpful to have a description of certain node settings that you might want to change.

Specifying a profile name

To create an FTP profile, you must specify a unique name for the profile. The Name setting is one of only two settings for which you must actively specify a value when creating an FTP profile; all other settings have default values.

Specifying a parent profile

Every profile that you create is derived from a parent profile. In the Parent Profile setting, you can select the default FTP profile as the parent profile, or you can select another FTP profile that you have already created.

Specifying a Translate Extended value

Because IP version 6 addresses are not limited to 32 bits (unlike IP version 4 addresses), compatibility issues can arise when using FTP in mixed IP-version configurations.

Enabled by default, the Translate Extended setting causes the Link Controller to automatically translate FTP commands when a client-server configuration contains both IP version 4 and IP version 6 systems. For example, if a client system running IP version 4 sends the FTP PASV command to a server running IP version 6, the Link Controller automatically translates the PASV command to the equivalent FTP command for IP version 6 systems, EPSV.

The Link Controller translates the FTP commands EPRV and PORT in the way.

It is highly unlikely that you will need to change the default value (Enabled) for this setting. The only case where you might want to disable this setting is when sending an EPSV command to an IP version 4 system, such as when testing an FTP server.

Specifying a data port

The Data Port setting allows the FTP service to run on an alternate port. You can use the default port number 20, or specify another port number.

Managing HTTP and FTP profiles

Using the Configuration utility, you can view HTTP and FTP profiles and delete any custom profiles that you have created. Note, however, that you cannot delete the default profiles http and ftp.

For the procedures on creating and modifying SSL profiles, see Chapter 16, Understanding Profiles .

To view an HTTP or FTP profile

  1. On the Main tab of the navigation pane, expand Local Traffic and then click Profiles.
    The main profiles screen opens.
  2. On the menu bar, from the Services menu, choose HTTP or FTP.
    This displays a list of any existing HTTP or FTP profiles.
  3. In the Name column, click the name of the profile that you want to view.

To delete an HTTP or FTP profile

  1. On the Main tab of the navigation pane, expand Local Traffic and then click Profiles.
    The main profiles screen opens.
  2. On the menu bar, from the Services menu, choose HTTP or FTP.
    This displays a list of any existing client-side or server-side profiles.
  3. Click the Select box to the left of the custom profile that you want to delete.
  4. Click the Delete button.
    A confirmation screen appears.
  5. Click the Delete button.



Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)