gzip
5 TopicsService 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?236Views0likes3Commentsgzip string compression?
Hi, I've been asked to send a JSON message containing various http headers and an XML payload from the HTTP request and HTTP response. Basically Logging the API calls and replies for downstream analytics. The XML payload is quite large most of the time and can be up to 5MB in size. Inspired by Hoolio's Log large HTTP payloads in chunks locally and remotely iRule I'm using HSL to send the JSON to a network server that's connected via Gig-E. However based on the amount of requests and responses in uncompressed form we are looking to get speeds of 6Gbps which will easily exceed the link speed. So I was looking to perform some form of compression on the JSON message that's being sent out using HSL::send but there doesn't seem to be a iRules method, function or library to perform string compression. Anyone have any ideas or suggestions? Can tcl libraries be manually added to a F5-BigIP? ie: in /usr/share/tcl8.4/ ? Cheers, Jason UPDATED: Sadly according to this sol15434: Overview of the HTTP Compression profile when activated by a COMPRESS::enable in an iRule only compresses the HTTP Response. 😞 Selective Compression: When checked (enabled), HTTP compression is performed only when a configured iRule contains the COMPRESS::enable command. When cleared (disabled), compression is performed according to the other compression settings specified in the HTTP Compression profile. Note: Data compression only compresses HTTP server responses, and not client requests.352Views0likes2CommentsCompression stripped by Silverline
We've recently experienced slowdowns serving web pages, and here's something we've found: Apparently, when traffic passes through the WAF, the WAF strips out the following line: Content-Encoding: gzip. We serve pages compressed with GZIP, but, from what we can see, the WAF strips that compression, severely slowing down the page delivery. Does this make sense to anyone, and is there a way to remediate this issue?510Views0likes2Commentsread a gzip response on sideband connection
Hi, I am trying to create a sideband connection to query a JSON webservice. I go through an intermediate VS for NAT and TLS. Everything is ok ... except that the answer is in GZIP ... and I can not read the answer in irule with the command 'rcev'. I have the characters unreadable. Do you have an idea ? - decode the gzip in the irule? - decompress the gzip at the intermediate level. - another idea? thank you in advance253Views0likes1CommentVS in BigIP returns uncompressed HTTP response that was compressed by the backend Apache server
Our backend servers run Apache and compress the HTTP data, however, it seems from the VIP associated to backend node is unpacking the compressed data and sending it out uncompressed. This was verified by executing curl: sending the request directly to the apache server returned compressed response while sending the same request to the corresponding VS resulted in the uncompressed response. Isn't the default behavior for VS to be in bypass mode (i.e. return response "as is")? Checked the BigIP VS configuration; it has HTTP Profile = http and HTTP Compression Profile = None. There's no iRule associated with the VS. What are we missing?Solved874Views0likes8Comments