An LTM Specialist configured a virtual server to load balance a custom application. The application works
when it is tested from within the firewall but it fails when tested externally. The pool member address is
192.168.200.10:80. A capture from an external client shows:
GET /index.jsp HTTP/1.1
Host: 207.206.201.100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Connection: keep-alive
HTTP/1.1 302 Found
DatE. Wed, 17 Oct 2012 23:09:55 GMT
Server: Apache/2.2.15 (CentOS)
Location: http://192.168.200.10/user/home.jsp
Content-LengtH. 304
Connection: close
What is the solution to this issue?

An LTM Specialist needs to rewrite text within an HTML response from a web server. A client is sending the
HTTP request below:
GET / HTTP/1.1
Host: www.f5.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-LanguagE. en-US,en;q=0.5
Accept-EncodinG. gzip, deflate
Cache-Control: no-cache
Connection: keep-alive
CookiE. somecookie=1Although a stream profile has been added to the virtual server, the content within the HTTP response is
NOT being matched, and therefore NOT modified.
Which HTTP header should the LTM Specialist remove from the request to ensure the content can be
matched and modified?

An LTM Specialist needs to rewrite text within an HTML response from a web server. A client is sending the
following HTTP request:
GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-LanguagE. en-US,en;q=0.5
Accept-EncodinG. gzip, deflate
Cache-Control: no-cache
Connection: keep-alive
CookiE. somecookie=1
HTTP/1.1 200 OK
Server: Apache/2.2.15 (Unix)
Last-ModifieD. Wed, 12 Aug 2009 00:00:30 GMT
Accept-Ranges: bytes
Content-LengtH. 1063
X-Cnection: close
Content-TypE. text/html; charset=UTF-8
Vary: Accept-Encoding
Content-EncodinG. gzip
Connection: Keep-Alive
Although a stream profile has been added to the virtual server, the content within the HTTP response is
NOT being matched and therefore NOT modified.
Which header field is contributing to the issue?

An LTM Specialist is troubleshooting an issue with a new virtual server. When connecting through the
virtual server, clients receive the message “Unable to connect” in the browser, although connections directly
to the pool member show the application is functioning correctly.
The LTM device configuration is:
ltm virtual /Common/vs_https {
destination /Common/10.10.1.110:443
ip-protocol udp
mask 255.255.255.255
pool /Common/pool_https
profiles {
/Common/udp { }
}
translate-address enabled
translate-port enabled
vlans-disabled
}
ltm pool /Common/pool_https {
members {
/Common/172.16.20.1:443 {
address 172.16.20.1
}}}
What issue is the LTM Specialist experiencing?

An LTM Specialist is troubleshooting an HTTP monitor. The pool member is accessible directly through a
browser, but the HTTP monitor is marking the pool member as down.
GET / HTTP/1.1
HTTP/1.1 400 Bad Request
DatE. Tue, 23 Oct 2012 21:39:07 GTM
Server: Apache/2.2.22 (FreeBSD) PHP/5.4.4
mod_ssl/2.2.22 OpenSSL/0.9.8q DAV/2
Content-LengtH. 226
Connection: close
Content-TypE. text/html; charset=iso-8859-1
Which issue is the pool member having?

The LTM device is configured to provide load balancing to a set of web servers that implement access
control lists (ACL) based on the source IP address of the client. The ACL is at the network level and theweb server is configured to send a TCP reset back to the client if it is NOT permitted to connect.
The virtual server is configured with the default OneConnect profile.
The ACL is defined on the web server as:
Permit: 192.168.136.0/24
Deny: 192.168.116.0/24
The packet capture is taken of two individual client flows to a virtual server with IP address
192.168.136.100.
Client A – Src IP 192.168.136.1 – Virtual Server 192.168.136.100:
Clientside:
09:35:11.073623 IP 192.168.136.1.55684 > 192.168.136.100.80: S 869998901:869998901(0) win 8192
<mss 1460,nop,wscale 2,nop,nop,sackOK>
09:35:11.073931 IP 192.168.136.100.80 > 192.168.136.1.55684: S 2273668949:2273668949(0) ack
869998902 win 4380 <mss 1460,nop,wscale 0,sackOK,eol>
09:35:11.074928 IP 192.168.136.1.55684 > 192.168.136.100.80: . ack 1 win 16425
09:35:11.080936 IP 192.168.136.1.55684 > 192.168.136.100.80: P 1:299(298) ack 1 win 16425
09:35:11.081029 IP 192.168.136.100.80 > 192.168.136.1.55684: . ack 299 win 4678
Serverside:
09:35:11.081022 IP 192.168.136.1.55684 > 192.168.116.128.80: S 685865802:685865802(0) win 4380
<mss 1460,nop,wscale 0,sackOK,eol>
09:35:11.081928 IP 192.168.116.128.80 > 192.168.136.1.55684: S 4193259095:4193259095(0) ack
685865803 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>
09:35:11.081943 IP 192.168.136.1.55684 > 192.168.116.128.80: . ack 1 win 4380
09:35:11.081955 IP 192.168.136.1.55684 > 192.168.116.128.80: P 1:299(298) ack 1 win 4380
09:35:11.083765 IP 192.168.116.128.80 > 192.168.136.1.55684: . ack 299 win 108
Client B – Src IP 192.168.116.1 – Virtual Server 192.168.136.100:
Clientside:
09:36:11.244040 IP 192.168.116.1.55769 > 192.168.136.100.80: S 3320618938:3320618938(0) win 8192
<mss 1460,nop,wscale 2,nop,nop,sackOK>
09:36:11.244152 IP 192.168.136.100.80 > 192.168.116.1.55769: S 3878120666:3878120666(0) ack
3320618939 win 4380 <mss 1460,nop,wscale 0,sackOK,eol>
09:36:11.244839 IP 192.168.116.1.55769 > 192.168.136.100.80: . ack 1 win 16425
09:36:11.245830 IP 192.168.116.1.55769 > 192.168.136.100.80: P 1:299(298) ack 1 win 16425
09:36:11.245922 IP 192.168.136.100.80 > 192.168.116.1.55769: . ack 299 win 4678
Serverside:
09:36:11.245940 IP 192.168.136.1.55684 > 192.168.116.128.80: P 599:897(298) ack 4525 win 8904
09:36:11.247847 IP 192.168.116.128.80 > 192.168.136.1.55684: P 4525:5001(476) ack 897 win 142
Why was the second client flow permitted by the web server?

A client is attempting to log in to a web application that requires authentication. The following HTTP
headers are sent by the client:
GET /owa/ HTTP/1.1
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
User-Agent: curl/7.26.0
Host: 10.0.0.14
Accept: */*
Accept-EncodinG. gzip,deflate
The web server is responding with the following HTTP headers:
HTTP/1.1 401 Unauthorized
Content-TypE. text/html
Server: Microsoft-IIS/7.5
WWW-AuthenticatE. NTLM
DatE. Wed, 16 Aug 1977 19:12:31 GMT
Content-LengtH. 1293
The client has checked the login credentials and believes the correct details are being entered.
What is the reason the destination web server is sending an HTTP 401 response?

A web developer has created a custom HTTP call to a backend application. The HTTP headers being sent
by the HTTP call are:
GET / HTTP/1.1
User-Agent: MyCustomApp (v1.0)
Accept: text/html
Cache-Control: no-cacheConnection: keep-alive
CookiE. somecookie=1
The backend server is responding with the following:
HTTP/1.1 400 Bad Request
DatE. Wed, 20 Jul 2012 17:22:41 GMT
Connection: close
Why is the HTTP web server responding with a HTTP 400 Bad Request?

A web application sends information about message integrity and content life time to the client.
Which two HTTP headers should be used in sending the client information? (Choose two.)

An HTTP 1.1 application utilizes chunking.
Which header should be used to notify the client’s browser that there are additional HTTP headers at the
end of the message?