Forum Discussion
NimbostratusASM_REQUEST_DONE and HTTP/1.1 POST request with Expect: header
Hello!
Can somebody tell me how i could check if my iRule is running in the right "context" for checking HTTP::uri during a ASM_REQUEST_DONE event?
My problem is, that we receive HTTP/1.1 requests with an "Expect: 100-continue" header and the request which is sent from the client after the server replies to that "Initial request", does not have any headers set, so there is no HTTP::uri, my code fails and the loadbalancer closes the connection, even when the ASM runs in transparent mode 😞
My code looks like this:
when ASM_REQUEST_DONE {
if { [ string tolower [HTTP::uri] ] matches_regex {^/[a-z0-9\-]+$} } {
log local0. "found short start URL [HTTP::uri], unblocking"
ASM::unblock
}
So what i would need before the "if string tolower..." stuff is a check which would tell me if there actually is a HTTP::uri.
The error message i get is
TCL error: /Common/ASM_Rule - Illegal argument. Can't execute in the current context. (line 2) invoked from within "HTTP::uri
For all of you who aren't familiar with those nasty POST-requests, i'll explain the data flow:
The client sends
3 Replies
Drew_128543I ran into this same problem just recently. You can get around the error by setting the uri as a variable in HTTP_REQUEST and use that
when HTTP_REQUEST { set uri [string tolower [HTTP::uri]] } when ASM_REQUEST_DONE { if { $uri matches_regex {^/[a-z0-9\-]+$} } { log local0. "found short start URL $uri, unblocking" ASM::unblock }HOWEVER! I then came across a new error. I no longer got the context errors, but instead starting getting the following for every unblock attempt.
warning tmm[12751]" 01480001:4: No Held transaction to sink.The Event Logs would even show as unblocked, but the traffic would make it through to the OWS. The only way I was able to get around this issue was to strip out the Expect header in my HTTP_REQUEST
when HTTP_REQUEST { if {(HTTP::method eq "POST") && ([HTTP::header exists "Expect"])} { HTTP::header remove "Expect" } }This adds an ~3 second delay but was finally able to unblock the traffic with ASM::unblock. Looking around it seems like Expect: 100-continues causes a bunch of issues across the board with F5 modules. This was on 11.6 HF1, not sure if it exists in 11.5.X.
-Drew
Andreas_LamprecThanks for you answer!
So if i understood you right, then HTTP_REQUEST event will not be raised for the "second" part of the HTTP/1.1 Post request?
How about following code:
when HTTP_REQUEST { if { [HTTP::header exists "Expect"] } { set expect_flag 1 } else { set expect_flag -1 } } when ASM_REQUEST_DONE { if( expect_flag != 0 } { do something to check if the request shall be unblocked and set "shall_be_unblocked" to 1 unblocking of all "normal" requests if { shall_be_unblocked == 1 && expect_flag < 0} { ASM::unblock } unblocking of POST requests with Expect header set if { shall_be_unblocked == 1 && expect_flag > 0 } { set expect_flag 0; ASM::unblock } } }This way, the actual POST request could be unblocked if nessesary, but the "second" part of the POST will not be handled by ASM_REQUEST_DONE
- Drew_128543My best guess at what is happening is that the ASM needs to see the entire POST for the ASM::unblock to work. By stripping the expect header, it forces the client to send the rest of the POST (after that ~3 second delay) before the ASM_REQUEST_DONE gets called. If you leave the Expect header in place, the ASM_REQUEST_DONE gets called before it has the entire post, so the HTTP::uri calls throw the context error, and the ASM::unblock fails to work. I am unsure how to get this work with leaving the Expect: 100-continue header in place (after I stripped the header out I had to move on to other tasks and was unable to continue testing).
