F5 irule points to websockets server, but no response back

Hi,

I know the original post here is about a month old but I have just set up our F5 to do just this. However we also have our iRule also restricting URIs based on a DataGroupList as below:

when HTTP_REQUEST { 
  if { [matchclass [HTTP::uri] starts_with $::MyValidUris] } {
        HTTP::disable
  } else {
    HTTP::respond 404 content [subst $::block_page]
  }
}

The problem I have is that once HTTP::disable is invoked, F5 can no longer parse the requests as HTTP and therefore cannot restrict URIs as before.

Is there anyway to re-enable the HTTP profile but selectively disable it when a websocket request comes through?

Imagine a web site like Amazon, that users can browse. At some point when they want to contact an agent via a "webphone", the site creates a websocket connection to the backend server. If when they want to carry on browsing the site and happen to change the URI on their browser go to an admin page, the iRule no longer restricts that URI. This is the problem I'm trying to work through. Any ideas on what I could do with my iRule would be greatly appreciated.

Thank you. Sachin

Try something like this:

when CLIENT_ACCEPTED {
    HTTP::enable
}
when HTTP_REQUEST {
    if { [matchclass [HTTP::uri] starts_with $::MyValidUris] } [
        HTTP::disable
    } else {
        HTTP::respond 404 content [subst $::block_page]
    }
}

Thank you for your reply.

I looked at the docs about this and they say that CLIENT_ACCEPTED is triggered when an entry is inserted in the BIG-IP connection table - meaning only once when the TCP connection is established.

It feels like that means if a website user were to navigate to an unrestricted part of the website, the HTTP profile would be disabled but never re-enabled as the TCP connection has already been established. Therefore allowing the user to change the URI to point at a restricted page.

Do you know if there is a trigger that's fired every time a request is made ... other than a HTTP trigger seeing as that might have been disabled?

I'm assuming the browser and websocket connections are actually different TCP sessions, so a new websocket TCP session would disable HTTP processing, based on URI in this case but could also be by method, while the browser session would not be affected.

Thank you Kevin. I took your code and modified it slightly. I've come up with a solution that works quite well. Here's my iRule. I'd be interested in getting your opinion.

Thank you again.

when CLIENT_ACCEPTED {
  HTTP::enable
}

when HTTP_REQUEST { 
  if { ([HTTP::uri] starts_with "/the-websocket-uri") } {
    HTTP::disable
  } elseif { [class match [HTTP::uri] starts_with UnrestrictedUris] } { 
     Do nothing by design - leaving the HTTP profile enabled
  } else {
     Drop the request
    drop
  } 
}

That looks good. I also see that you went from matchclass to class match. You could technically streamline a little bit more by negating the UnrestrictedUris condition:

when CLIENT_ACCEPTED {
    HTTP::enable
}
when HTTP_REQUEST { 
    if { ([HTTP::uri] starts_with "/the-websocket-uri") } {
        HTTP::disable
    } elseif { not ( [class match [HTTP::uri] starts_with UnrestrictedUris] ) } { 
         Drop the request
        drop
    } 
}

Perfect! I noticed that matchclass had been deprecated in v10 which is what I have, so thought it best to use the class command instead.

Thank you :-)