Forum Discussion
HTTP_RESPONSE event failure
does anyone have an explanation to explain the following behavior?
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.
11 Replies
- I've written several iRules dealing with POSTs and haven't run into the problem you are encountering, but I can tell you it's fairly common to see the headers in one packet and the data in a second for POST requests.
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 - the server responds with a HTTP 401 which I've confirmed with tcpdumps. (this is correct behavior for the site).
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 - ah, NTLM auth is somewhat of a special case.
What version are you running?
And do you have a OneConnect profile applied to the virtual server?
/deb - it's 9.1.2 with no hotfixes and there is no Oneconnect in the picture
- There is a known issue with OneConnect transformations (enabled by default in the http profile, rather than the OneConnect profile) and NTLM authentication. AskF5 Solution detailing the issue is here: Click here
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 - Interesting. I'll ask the customer to re-test without oneconnect transforms enabled, thanks.
- The only reason why HTTP_RESPONSE would not fire was if 1) you have disabled the event in a prior rule or 2) the response is not complete (missing terminators) or well formed. If in your case its neither of the two case, you might be running into a bug. Please open a support case and provide a tcpdump.
- Your post in this forum is not the same as an open Support case.
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 . - i know. I am the F5 support engineer working the case. If this turns out to be a new issue I'll post the CR number.
Aragorn_5898Nimbostratus
Hello,
Maybe the Response is coming from LTM caché..
How can I use HTTP_RESPONSE on cache responses?
