Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

iRule for supporting WebSocket in LTM v10.2.4

Hi,

We had developed an iRule for support WebSocket in LTM v10.2.4 HF7 (Although 11.4 had native support, but we had no plan to upgrade currently)

Sample handshake (http://en.wikipedia.org/wiki/WebSocket#WebSocket_protocol_handshake)

when HTTP_RESPONSE {
  # if status code is 101 (Switching Protocols) and there exists HTTP header "Upgrade: WebSocket",
  # that means we are switching to WebSocket and thus HTTP filter shall be disabled
  # use case insensitive matching
  if { [HTTP::status] == 101 && "websocket" eq [string tolower [HTTP::header value "Upgrade"]] } {
    HTTP::disable
  }
}

But it does not work. Adding debug message found that I never saw HTTP::status returns 101 (I had confirmed with tcpdump that the server did reply with status code 101). So I doubt that there are something wrong for handling this status code in LTM v10.2.4 HF7.

Currently I had used the following iRule which is less secure as it will disable HTTP filter once client request to switch to WebSocket without confirmation from server.

when HTTP_REQUEST {
  # if client request contains a HTTP header "Upgrade: WebSocket", it indicate
  # the client intended to switch to WebSocket, we shall disable HTTP filter here

  # it is not very secure as we shall wait for response from server to confirm with
  # status code 101 (Switching Protocols) with HTTP header "Upgrade: WebSocket"
  # but it seems that LTM 10.2.4 HF7 have problem on that status code,
  # so we have to workaround it.

  # use case insensitive matching
  if { "websocket" eq [string tolower [HTTP::header value "Upgrade"]] } {
    HTTP::disable
  }
}

2 questions 1. Is there any problem in the support of status code 101 in LTM v10.2.4 HF7? 2. Any existing iRule for supporting WebSocket?

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I can't answer either of your questions I'm afraid but I wonder, what would be wrong in your first rule in just checking for the Upgrade header?

0
Comments on this Answer
Comment made 20-Nov-2013 by kwkyiu 5
It would be more complete and a bit faster by checking the status code in the first place. Also, I doubt that the HTTP filter may hung when it saw status code 101 and will not trigger the corresponding HTTP_RESPONSE at all.
0
Comment made 22-Nov-2013 by What Lies Beneath 6708
Fair enough. Thanks.
0