301b Exam - Question 87

Question

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?

Examice · Accepted Answer

The header field contributing to the issue is the Accept-Encoding header. Stream profiles typically work on the uncompressed body of the HTTP response. The Accept-Encoding header in the client request indicates that the client can accept compressed responses like gzip or deflate. Since the server sends a compressed response (as indicated by Content-Encoding: gzip), the LTM device might not be decompressing it before applying the stream profile, causing the content within the HTTP response to not be matched or modified.

GVKD · Answer

D - Correct
Stream profiles typically work on the uncompressed body of the HTTP response.
The Accept-Encoding header in the client request indicates that the client can accept gzip or deflate compressed responses.
If the server sends a compressed response (as suggested by Content-Encoding: gzip), the LTM device might not be decompressing it before applying the stream profile, leading to unmatched patterns.

301b Exam - Question 87

Discussion