when making an HTTP POST, the client (IE+.NET) sends the HEADERS ONLY in the first packet (without respect of content length), the
IIS6 server responds immediately (this occurs before the content-length number of bytes has been processed by BIG-IP) and the HTTP_RESPONSE event in the iRule isn't triggered.
I'd be surprised if the server is responding with other than a 100 Continue before seeing the POST data, and even then, it should trigger HTTP_RESPONSE.
It would be helpful to see both the iRule and a packet trace showing the data exchanged, along with a better description of the functionality you are trying to achieve.
/deb
Using a test iRule that logs on event we've confirmed that the HTTP_RESPONSE event isn't being triggered
rule test_rule {
when HTTP_REQUEST {
set inbound_debug "In http_request"
log local0.info $inbound_debug
}
when HTTP_RESPONSE {
set debug "in rule"
log local0.info $debug
}
when HTTP_RESPONSE_DATA {
log local0.info "In HTTP_RESPONSE_DATA"
}
when HTTP_RESPONSE_CONTINUE {
log local0.info "In HTTP_RESPONSE_CONTINUE"
}
when SERVER_CLOSED {
log local0.info "In SERVER_CLOSED"
}
when SERVER_CONNECTED {
log local0.info "In SERVER_CONNECTED"
}
when SERVER_DATA {
log local0.info "In SERVER_DATA"
}
}
This is what gets logged when we hit the application:
Jun 28 10:32:05 tmm tmm[817]: Rule test_rule : In http_request
Jun 28 10:32:05 tmm tmm[817]: Rule test_rule : In SERVER_CONNECTED
Jun 28 10:32:07 tmm tmm[817]: Rule test_rule : In http_request
Jun 28 10:32:07 tmm tmm[817]: Rule test_rule : In SERVER_CONNECTED
Jun 28 10:32:07 tmm tmm[817]: Rule test_rule : In http_request
Jun 28 10:32:08 tmm tmm[817]: Rule test_rule : In SERVER_CLOSED
Jun 28 10:34:15 tmm tmm[817]: Rule test_rule : In SERVER_CLOSED
the post header that generated the above logs:
POST /inventory/FormsAccess.jsp HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 1.1.4322.2032)
Content-Type: text/xml; charset=utf-8
SOAPAction: "http:///Applications/myApp/GetList"
Content-Length: 340
Expect: 100-continue
Connection: Keep-Alive
Host:
the response header from the server:
HTTP/1.1 401 Unauthorized
Content-Length: 1656
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm=""
X-Powered-By: ASP.NET
Date: Thu, 28 Jun 2007 15:32:04 GMT
So it looks like there is some sort of qualification in the HTTP_RESPONSE event that this particular circumstance isn't meeting beyond there being an HTTP response header in the packet. I'm looking for what that is so I can determine if it is a bug or not.
- i
What version are you running?
And do you have a OneConnect profile applied to the virtual server?
/deb
Not sure what effect that checkbox option has if you don't have the OneConnect profile applied as well, but I'd start by modifying the http profile to disable OneConnect transformations.
HTH
/deb
What bl0ndie meant was that you need to contact F5 Support and work with them to determine whether you are encountering a product defect.
If you have a Support contract, you can open a Support case using the web support portal @ https://websupport.f5.com/ and providing your product serial .
Nimbostratus
Maybe the Response is coming from LTM caché..
How can I use HTTP_RESPONSE on cache responses?
