HTTP Profile

Managing Application Layer  HTTP Traffic.

Specifying a realm for basic authentication

The value of the Basic Auth Realm setting is a string that you provide. The BIG-IP system 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.

Redirection to a fallback host occurs if all members of the targeted pool are unavailable, or if a selected pool member is unavailable. (The term unavailable refers to a member being disabled, marked as down, or having exceeded its connection limit.) When one or more pool members are unavailable, the BIG-IP system can redirect the HTTP request to the fallback host, with the HTTP reply Status Code 302 Found.

Although HTTP redirection often occurs when the system generates an LB_FAILED iRule event, redirection can also occur without the occurrence of this event, such as when:

The selected node sends an RST after a TCP 3WHS has completed, but before the node has sent at least a full response header. The BIG-IP system finds the selected node to be unreachable while receiving the body portion of a request or a pipelined request.

When configuring the BIG-IP system 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.

Virtual Server에 limit도달했을 경우에는 동작하지 않음

 

Specifying fallback error codes

In addition to redirecting traffic when a target server becomes unavailable, you can also specify the HTTP error codes from server responses that should trigger a redirection to the fallback host. Typical error codes to specify in the Fallback Error Codes setting are 500, 501, and 502.

When you type the error codes in the Fallback Error Codes box, you separate the codes with a space, such as 500 501 502. You can also specify a range of error codes, as in this example: 505-515.

 

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 BIG-IP system then inserts the header specified in the profile into any HTTP request that the BIG-IP system sends to a pool or pool member.

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

Request header에 특정항목을 추가하는 기능으로 이미 존재하는 항목의 값은 바꿀 수 없다.

  

Erasing content from HTTP headers

Another optional setting is the Header Erase setting. Using this setting, you can configure a profile to erase the contents of a header from an HTTP request that is being sent from a client to a server. 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.

When you use this setting, the BIG-IP system erases the contents of the specified header and replaces that content with blank spaces. The header itself is retained.

Note: This feature does not apply to HTTP responses being sent from a server to a client.

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 Request Headers Erase setting and type a value.

Request header중 특정항목을 제거하는 기능이다.

 

 

Allowing headers in an HTTP response

Using the Configuration utility, you can specify any headers within an HTTP response that you want the BIG-IP system to allow. To do this, type a value in the Response Headers Allowed box. If you are specifying more than one header, separate the headers with a blank space. For example, if you type the string Content-Type Set-Cookie Location, the BIG-IP system then allows the headers Content-Type, Set-Cookie, and Location.

Response Header에 허용할 항목을 정의하는 기능이다. 테스트 결과 Content관련내용이 삭제가 되지 않는다. 이유는 잘 모르겠음.

  

HTTP1.1은 컨텐츠 전송 인코딩 개념을 Content-Encoding과 Transfer-Encoding으로 2단계 분리했다. 첫번째는 HTTP 메시지에 있는 실체를 변환하기 위해 사용하는 컨텐트 인코딩이다. 두 번째는 안전한 전송을 보장하기 위해 HTTP 메시지 전체를 인코딩하는 전송 인코딩이다. 통신의 효율성을 향상시키기 위해 실체를 압축할 컨텐트 인코딩을 쓴다. 그리고 주로 메시지의 끝을 식별하는 문제를 해결하기 위해 전송 인코딩을 사용한다.

그러나 TCP의 중요한 성질 중 하나는 구조화되지 않은 바이트 스트림으로 모든 데이터를 전송한다는 것이다. TCP 자체는 데이터의 시작과 끝을 구분하는 어떠한 방법도 제공하지 않으며, 이 문제를 어플리케이션에 위임했다. HTTP는 이미 Content-Length 헤더를 가지고 있었기 때문에 TCP의 문제점을 해결할 수 있었다. 그러나 동적 자원이 많은 오늘날의 웹 트래픽에서는 파일의 길이를 전송시에 알 수 없다는 한계에 직면하게 되었다.

HTTP Chunking
파일의 길이를 알 수 없는 문제를 처리하기 위해 HTTP 개발자들은 Chunking이라는 특별한 전송 인코딩 방법을 개발했다. 청크 기술을 사용할 경우, 실체는 바이트 배열 그대로 전송되는 대신 청크로 나뉜다. 이는 HTTP가 동적으로 생성되는 자원을 소프트웨어에서 데이터를 처리할 때마다 한 번에 한 조각씩 전송하는 것을 가능하게 한다. 이 메소드를 사용했다는 것을 표시하기 위해 Transfer-Encoding: chunked가 메시지 안에 삽입된다. 그리고 청크를 구분하기 위해 HTTP 메시지의 본문에 특수한 형식이 사용된다.  청크의 길이는 16진수로 지정되며, ASCII 문자를 이용하여 표시된다. 모든 청크 길이와 청크 데이터는 CRLF로 끝난다. 수신자는 길이가 0인 청크를 받으면 마지막 청크를 수신했음을 알게 된다.

 

Configuring chunking

Sometimes, you might want to inspect and/or modify HTTP application data, such as compressing 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 BIG-IP system 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 Selective.

Table 6.3 describes each of these values and the action that the BIG-IP system takes, depending on whether an original response is chunked or unchunked.

Table 6.3 Chunking behavior of the BIG-IP system
Setting	Original response is chunked	Original response is unchunked
Unchunk	The BIG-IP system 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 BIG-IP system processes the HTTP content and passes the response on untouched.
Rechunk	The BIG-IP system 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 BIG-IP system adds transfer encoding and chunking headers on egress.
Selective	Same as Rechunk.	The BIG-IP system processes the HTTP content and then passes the response on untouched.
Preserve	The BIG-IP system leaves the response chunked, processes the HTTP content, and passes the response on untouched. Note that if HTTP compression is enabled, the BIG-IP system does not compress the response.	The BIG-IP system processes the HTTP content and then passes the response on untouched.

HTTP/1.0 프로토콜의 문제점

HTTP/1.0 프로토콜의 특징은 단순성에 있다. 그래서 연결을 만들고 동작하고 연결을 해제하는 단순한 과정으로 구성되어 있으며, 하나의 URL은 하나의 TCP 연결이 되도록 만들어져 있다. 연결의 설립/동작/해제의 단순 동작이 계속 반복됨으로해서 네트워크의 congestion에 대한 정보를 확보할 수가 없었다. 연결이 계속 지속되어 있다면 정보 축적과 분석을 통해 트래픽의 혼잡을 인식할 수 있는 것이다. 또한 잦은 연결 설립과 동시에 여러 개의 연결을 설립하는 동작을 통해 bandwidth가 낮은 링크에서 congestion 문제의 가능성을 높이고 사용자에게는 불만족스런 성능을 제공해주게 된다. 캐시 모델의 미흡함도 문제이다. 캐싱에 관해 설계한 모델이 초기적인 형태로 구성되었기 때문에 동작상의 오버헤드도 만들고 캐시된 데이타 관리에도 문제를 갖고 있었던 것이다. 이러한 문제들을 해결하고, 추가적인 고려 사항을 반영한 HTTP/1.1 프로토콜을 설계하게 된 것이다.

 

Enabling or disabling OneConnect transformations

This setting enables or disables part of the OneConnectTM feature. When enabled, this setting performs HTTP Connection header transformations on HTTP/1.0 requests, for the purpose of implementing Keep-Alive support for connection persistence. Thus, when a client sends an HTTP/1.0 request with a Connection: Close header, this feature forces the connection to remain open by transforming the header to Connection: Keep-Alive. The default value for this setting is Enabled.

Important: To enable this setting, you must also enable the connection pooling component of the OneConnectTM feature. You enable connection pooling by configuring a OneConnect profile. For more information on connection pooling and configuring a OneConnect profile, see Chapter 5, Understanding Profiles.

For general information on the OneConnectTM feature, see Chapter 1, Introduction to Local Traffic Management.

To enable OneConnect transformations, locate the OneConnect Transformations setting and check the box.

•          address translation will be performed on the client IP address.

•          클라이언트의 IP를 바꾸어 해당 기능을 수행하므로 web application에서 IP를 이용하여 기능구현을 하였을 경우 문제가 될 수 있음.

•          web server must support HTTP Keep-Alive connections.

•          해당기능을 사용할 경우 Mirror기능을 사용하지 않는다.

빅아이피는 Full proxy로 동작하므로 Client의 연결과 Server의 연결이 독립적이어서 클라이언트와의 연결만 끊고 서버와의 연결을 끊지 않아 재사용한다.

The following OneConnect profile settings control OneConnect behavior and affect server-side connections:

The Source Mask setting specifies the mask applied to the source IP address to determine the connection's eligibility to reuse a server-side connection. For more information, refer to SOL5911: Managing connection reuse using OneConnect source mask.

The Maximum Size setting represents the maximum number of idle server-side connections kept in the connection pool.

The Maximum Age setting represents the maximum number of seconds a server-side connection is allowed before the connection is deleted from the connection pool.

The Maximum Reuse setting represents the maximum number of requests to be sent over a server-side connection. This number should be slightly lower than the maximum number of HTTP Keep-Alive requests accepted by backend servers in order to prevent the backend server from initiating connection close and entering the TIME_WAIT state.

The Idle Timeout Override setting represents the maximum time idle server-side connections will be kept open. Lowering this value may result in a lower number of idle server-side connections, but may increase request latency and server-side connection rate.

 

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 BIG-IP system 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 BIG-IP system 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 BIG-IP system to change that IP address to the virtual server address.

Table 6.4 shows examples of how redirections of client requests are transformed when the BIG-IP system is listening on port 443, and the Rewrite Redirections setting is enabled.

Table 6.4 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 6.5 shows examples of how redirections of client requests are transformed when the system is listening on port 4443, and the rewrite feature is enabled.

Table 6.5 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 BIG-IP system 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 BIG-IP system to rewrite the redirected URI to go to https://www.sample.com/bar/ instead. (Note the addition of the trailing slash.)

 

Encrypting and decrypting cookies

You can use the Configuration utility to encrypt one or more cookies that the BIG-IP system sends to a client system. When the client sends the encrypted cookie back to the BIG-IP system, the system decrypts the cookie.

To encrypt a cookie, use the Encrypt Cookie setting to specify the name of the cookie that you want to the BIG-IP system to encrypt. If you want to specify more than one cookie, simply separate the cookie names with a space.

After specifying one or more cookie names, use the Cookie Encryption Passphrase and the Confirm Cookie Encryption Passphrase boxes to type a passphrase for the cookie.

 

Specifying the maximum header size

With the Maximum Header Size setting, you can specify the maximum size that the BIG-IP system allows for HTTP headers. The default value is 32768 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 BIG-IP system.

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

 

 

일반적으로 HTTP request들은 연속적으로 발생하며, 순서적으로 다음 request는 항상 이전 request에 대한 response가 완전히 'received' 되고 나서 issue 되어 서버로 전달된다. 이것은 종종 bandwidth의 제약이나 network latencies 문제들로 인하여, 서버상에서 '심각한' 지연 현상을 일으키는 것을 관찰 할 수 있다.

HTTP/1.1은 다수의 HTTP request들이 1개의 socket에 함께 write 되고 (response를 기다리지 않는다.) browser는 전달된 request들에 대한 response를 '순차적'으로 기다리는 메커니즘을 제공한다. 이것은 사실상 '서버'의 mechanism이 아니라 클라이언트의 mechanism에 의존하는 경향이 강하며, (대게의 경우 server는 TCP multiplexing을 통해 다수의 request를 '한' socket에서 받아들일 준비가 되어 있다.) 이를 통해 network latency 및 delay를 현명하게 줄일 수 있다. 이러한 기법을 HTTP/1.1에서 우리는'파이프라이닝(Pipelining)' 이라고 부른다.

Pipelining은 TCP/IP의 packet 수를 상당히 줄일 수 있다. typical MSS(Maximum Segment Size)는 보통 536 에서 1460 byte까지 가능한데, 몇 개의 HTTP request들을 하나의 TCP/IP packet으로 packing하는 것이 Pipelining을 통해 가능해진다. 하나의 페이지를 load 하는 데에 필요한 packet의 갯수를 줄임으로써, 전체 인터넷상의 bandwidth가 절약된다는 잇점이 바로 또하나의 piplining의 장점이 될 수 있는 것이다.

HTTP/1.1은 서버가 또한 pipelining을 지원하도록 요구하고 있다. 그러나 이것이 서버가 response를 pipeline 할 수 있어야 한다는 것을 의미하지는 않으며, 다만 서버들은 client가 request를 pipelining 했을 때 그 request를 성공적으로 읽어들일 수 있어야 한다는 것을 의미한다.

2) When should we pipeline requests?

Pipelining은 모든 METHOD에 적용될 수 있는 것은 아니다. idempotent 한 METHOD 즉, GET/HEAD 요청만이 Pipeline 화 될 수 있으며, POST와 PUT과 같은 방식에는 적용될 수 없다. 우리는 또한 '첫번째 request'를 pipeline 속에 넣을 수 없으며, Pipelining은 단지 존재하는 'KEEP-ALIVE' connection을 재사용할 수 있을 뿐이다.

3) How many requests should be pipelined?

많은 수의 request를 pipelining하는 것은 만약에 connection이 prematurely하게 close 되었다면 그 cost가 높을 수 있는데, 이는 우리는 보통 request를 network으로 'write' 하는데 wasted time을 가질 뿐만 아니라, 새로운 connection 상에서 이것들을 반복해야만 하기 때문이다. 게다가, longer pipe-line은 실제로 유저가 '인식할 수 있을' 만한 delay를 유발하며, 이전 request들이 실제 사용자 클라이언트 상에서 complete 되는데 꽤 시간이 걸릴 수 있다. HTTP/1.1은 따라서, 얼마나 '많은'수의 request를 piplelining하라는 권고를 하지는 않는다. 다만, 이것은 application에서 책임을 지는 부분이며, 일반적으로 서버 당 2개 이상의 keep-alive connection을 쓰지 않기를 권고한다. 하지만 이 부분도 application에 상당히 의존적이며, web browser의 경우 그것은 '장시간' 동안 pipeline을 위해 시간을 낭비하지 않도록 구성되어있다. 아마도 2개의 keep-alive 세션은 적절한 value 이나, 이것은 사용자 application에 따라 test 되어져야 한다.

4) What happens if a request is canceled?

만일 request가 취소된다면, 전체 pipeline이 취소되는 것인가? 혹은 cancel된 request만 simple 하게 버려지는 것일까? (response 상에서) Navie하게 접근해보면, pipeline이 cancel 되어지며, 이 pipeline은 다시 모든 request를 재 issue하게 될 것이다.

5) What happens if a connection fails?

만일 connection이 fail 되거나 서버에 의해 특정 부분이 download되는 과정에서 '삭제' 된다면, web browser는 아마도 lost 된 request를 '재시작' 할 것이다. 이 경우, cancel과 동일하게 동작될 수 있다.

 

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 into a request. When you configure the BIG-IP system to insert this header, the target server can identify the request as coming from a client other than the client that initiated the connection. The default setting is Disabled.

 

Configuring the maximum columns for linear white space

The LWS Maximum Columns 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. The default value for this setting is 80.

 

Configuring a linear white space separator

The LWS Separator setting specifies the separator that the BIG-IP system 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. This setting has no default value.

 

Specifying a maximum number of requests

The Maximum Requests setting specifies the maximum number of requests that the system allows for a single Keep-Alive connection. When the specified limit is reached, the final response contains a Connection: close header is followed by the closing of the connection. The default setting is 0, which in this case means that the system allows an infinite number of requests per Keep-Alive connection.