How to implement http delete in f5 LTM

Hi Kirit,

 

 

What do you want to do with an HTTP DELETE request? Is this a request a client is sending through an LTM virtual server? Or something else? LTM should be able to successfully proxy any HTTP method through a virtual server to a pool.

 

 

Aaron

Aaron

 

 

Its coming through ltm. Does the default http profile do http delete ?

 

The HTTP traffic should be proxied through to the pool regardless of the method.

 

 

Aaron

Umm... What do you get back?

In some versions of LTM (Maybe still all, it's been a while since I did it, although the SOL note says the ones listed in the SOL were fixed in 9.3) the HTTP profiles didn't like various commands such as 'CONNECT' and others... It's possible that 'DELETE' is one of them (Sorry. Memory must be going üôÇ

It's possible that the HTTP profile still doesn't pass it through (It only passes methods it actually parses). If it doesn't, you can write an iRule to disable HTTP processing if a DELETE method is sent.

e.g. (From SOL7581: and the iRule on codeshare http://devcentral.f5.com/wiki/default.aspx/iRules/DisablingHTTPProcessingForUnrecognizedHTTPMethods.html )

when CLIENT_ACCEPTED {
    Enable HTTP processing for all requests by default
   HTTP::enable
}
when HTTP_REQUEST {
    selectively disable HTTP processing for specific request methods
   switch [HTTP::method] {
      "MOVE" -
      "COPY" -
      "LOCK" -
      "UNLOCK" -
      "PROPFIND" -
      "PROPPATCH" -
      "MKCOL" { HTTP::disable }
   }
}

Per SOL7581 that was fixed ages ago, so I think DELETEs should be handled fine with an HTTP profile enabled on any recent version.

 

 

http://support.f5.com/kb/en-us/solutions/public/7000/500/sol7581.html

 

F5 Networks Product Development tracked this issue as CR73219, and it was fixed in BIG-IP LTM versions 9.3 and 9.4.2.

 

 

Aaron

@Hamish: this problem may be solved already, but I really like that rule! Nice one.

 

 

-Matt

I always cringed when I see HTTP::disable as it disables the HTTP filter for the rest of the TCP connection. So even if you can't put the current request/response through the HTTP proxy for some reason, you don't get any further HTTP events (or HTTP load balancing, persistence, etc) for the life of the connection. I wish there was a simple way to detect the end of the next HTTP response and automatically re-enable the HTTP filter.

 

 

Aaron

Yeah.

 

 

Oh... That iRUle isn't mine BTW... It was someone else.

 

 

IIRC I did post mine that was done for a forward proxy being load balanced. But I think it was just posted in the forums (About 3 years ago now), and not on codeshare. FWIW ISTR that we also did a 'connection: close' after the reply was finished when disabling...

 

 

H

That's a good option. I'll add that to the HTTP::disable wiki page :)

 

 

Thanks, Aaron