Forum Discussion
Jon_Strabala_46
Nimbostratus
NimbostratusHow to use HTTP::respond to send a 1x1 gif
Hello,
I am trying to write a simple iRule to that uses HTTP::respond (from HTTP_REQUEST) to send a 1x1 gif back to the client on any request.
I build a 1x1 gif (44 bytes) but somehow it expands into 67 bytes at the client any ideas on what I am doing wrong?
- Jon
when RULE_INIT {
set ::t1x1gif \x47\x49\x46\x38\x39\x61\x01\x00\x01\x00\x80\x00\x00\xff\xff\xff\xff
append ::t1x1gif \xff\xff\x21\xf9\x04\x01\x0a\x00\x01\x00\x2c\x00\x00\x00\x00\x01\x00
append ::t1x1gif \x01\x00\x00\x02\x02\x4c\x01\x00\x3b\x00
log local0. "length of 1x1 transparent gif == [string length $::t1x1gif]"
}
when HTTP_REQUEST {
The GIF is 44 bytes, but the Response Header says "Content-Length67" - and it is not a legal image
what am I doing wrong ?
log local0. "respond with a 1x1 transparent gif"
HTTP::respond 200 content $::t1x1gif "Accept-Ranges" "bytes" "Content-Type" "image/gif" "Content-Length" 44 "Dummy" 1999
HTTP::respond 200 content $::t1x1gif "Accept-Ranges" "bytes" "Content-Type" "image/gif"
}
-------------
request ...
-------------
(Request-Line)GET /prox_evdo/auth.gif HTTP/1.1
Host10.0.185.150
User-AgentMozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Acceptimage/png,image/*;q=0.8,*/*;q=0.5
Accept-Languageen-us,en;q=0.5
Accept-Encodinggzip,deflate
Accept-CharsetISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive115
Connectionkeep-alive
-------------
response ...
-------------
(Status-Line)HTTP/1.0 200 OK
Accept-Rangesbytes
Content-Typeimage/gif
Dummy1999
ServerBigIP
ConnectionKeep-Alive
Content-Length67
-------------
ltm log
-------------
Feb 3 10:57:41 local/tmm1 info tmm1[21110]: Rule serve_gif : length of 1x1 transparent gif == 44
Feb 3 10:58:44 local/tmm info tmm[21109]: Rule serve_gif : respond with a 1x1 transparent gif
7 Replies
- The_BhattmanHi Jon,
Did you account for the extra length for other characters such as the content type?
Thanks,
Bhattman 
hoolioCirrostratus
The content-type would be inserted in the response headers and not count as part of the content-length. LTM generates the content-length header irrespective of it being set in the iRule.
I'd guess the \xDD characters are being converted internally to something you're not expecting. The simplest option I've seen is to base64 encode the image and then use b64decode and HTTP::respond to decode and send it to the client:
http://devcentral.f5.com/wiki/default.aspx/iRules/LTMMaintenancePage.html
Aaron
Jon_Strabala_46Thanks Aron, this worked greatwhen RULE_INIT { prepare a (44 byte transparent) gif for short-circuit injections set ::base641x1tgif "R0lGODlhAQABAIAAAP///////yH5BAEKAAEALAAAAAABAAEAAAICTAEAOwA=" set ::i1x1tgif [b64decode [lindex $::base641x1tgif 0]] } when HTTP_REQUEST { HTTP::respond 200 content $::i1x1tgif noserver "Content-Type" "image/gif" HTTP::respond 200 content $::i1x1tgif "Content-Type" "image/gif" }
Note, you do not need to account for the extra length for other characters such as the content type. You can and 1-N response headers at in the response this is not considered content.
Jon- Jon_Strabala_46There are a few uses
1
The 1x1 gif can be used as a web beacon (injected into all response content) this results in Google Analytics style information being sent to the ISP that uses the F5. Imaging that you only want to track a a single user or a subset of subset of users. Having the F5 short circuit the beacon request by injecting a 1x1 gif (without the request hitting the beacon server) effectively turns off tracking tracking. This allows selective tracking to meet the needs of Communications Assistance to Law Enforcement Act (CALEA)
2
Use the 1x1 gif request to perform authentication (sideband style) once the connection/session is authenticated, have the F5 short circuit the beacon request by injecting a 1x1 gif. This limits the load on the sideband auth server
- Jon - hoolioIf it's for CALEA compliance, can I take back my suggestion? :D
Aaron - hoolioIt was kind of a joke. I'm in London these days, so I'm not subject to any kind of pervasive surveillance...
Aaron - The_Bhattman...so you think...:-)
