accept-encoding
2 TopicsUnderstanding STREAM expression and Compression
Hello - I have a question to try and confirm my understanding around using STREAM and compression. I'm aware of the need to disable compression so STREAM is able to inspect the payload, but after the STREAM expression has done it's replacing, is or can, the content be compressed to improve performance or is this lost? In our set-up, we have physical LTMs that handle SSL offloading (part of the cloud solution we use) and virtual LTMs that we configure for service specific iRules etc. So on the physical LTM with SSL offload, there is STREAM (blank) and iRule to replace http:// with https:// on the response with the following: when HTTP_REQUEST { PHYSICAL LTM WITH SSL OFFLOAD tell server not to compress response HTTP::header remove Accept-Encoding disable STREAM for request flow STREAM::disable } when HTTP_RESPONSE { catch and replace redirect headers if { [HTTP::header exists Location] } { HTTP::header replace Location [string map {"http://" "https://"} [HTTP::header Location]] } only look at text data if { [HTTP::header Content-Type] contains "text" } { create a STREAM expression to replace any http:// with https:// STREAM::expression {@http://@https://@} enable STREAM STREAM::enable } } On the virtual LTM, we have a similar entry in the iRule: when HTTP_REQUEST { VIRTUAL LTM tell server not to compress response HTTP::header remove Accept-Encoding disable STREAM for request flow STREAM::disable } when HTTP_RESPONSE { catch and replace redirect headers if { [HTTP::header exists Location] } { HTTP::header replace Location [string map {"://internal.url" "://external.url"} [HTTP::header Location]] } only look at text data if { [HTTP::header Content-Type] contains "text" } { create a STREAM expression to replace any http:// with https:// STREAM::expression {@://internal.url@://external.url@} enable STREAM STREAM::enable } } So in this set-up, we we loose the benefit of HTTP compression? Thanks654Views0likes1CommentService breaks when upgrading from 11.3 to 11.5.1
We have a non-browser based service that works on 11.3 but breaks on 11.5.1. Testing is performed using SoapUI... Here is the request that is sent to both 11.3 and 11.5.1: POST HTTP/1.1 Connection: close Accept-Encoding: gzip,deflate Content-Type: text/xml;charset=UTF-8 SOAPAction: "" Content-Length: 680 Host: x.x.x.x:443 User-Agent: Apache-HttpClient/4.1.1 (java 1.5) http://schemas.xmlsoap.org/soap/envelope/" xmlns:iden="http://xxxx.com/xxxx" xmlns:rxc="http://xxxx.xxxxx.xxxxx.xxxx.com/xxxx/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xxxxxxxx xxxx Here is a good 11.3 response: HTTP/1.1 200 OK Content-Type: text/xml;charset=UTF-8 Content-Encoding: gzip Connection: close http://schemas.xmlsoap.org/soap/envelope/"> ;http://xxxx.xxxxxxx.xxxxxx.xxxxx.com/xxx/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" /> Here is a bad 11.5.1 response: HTTP/1.1 **202** Accepted Content-Type: text/xml;charset=UTF-8 Content-Length: 0 Connection: close Set-Cookie: bbbbbbbbbbbbbbb=FBPHCLGKAACCJNJOBEEPKHOMIJDCALHJHKAKEALGKLNDHFFCBKAMPAJOGAOACCFIACJDCAPEABPIOLKJCOFOMOLHLBKLMNKLKLBFONHDEFKKNCEIDJHKPNMBHDBDOKDF; HttpOnly; secure I have not modified the string directly above, that's the way it appears in the response. I'm thinking it has something to do with the "gzip" format and how 11.5.1 handles it. Both VIPs are configured identically. HTTP Compression is not enabled, it's a pretty basic VIP config, no special profiles or rules. Has anyone run into this? Any thoughts?236Views0likes3Comments