Allow binding of websocket profile without HTTP profile creation in AS3

[Eken92]

Is your feature request related to a problem? Please describe.

When creating an AS3 declaration we are forced to create a new HTTP profile in order to bind a websocket profile. If we're not "missing something obvious" - this seems to be quite tedious/problematic if we just want websockets allowed for a few services. Using the normal BIG-IP configuration all you need to do is to bind a Websocket profile to the virtual server.

Let's say that we want to use the standard HTTP profiles that comes pre-configured with F5 (not keeping them in AS3) then I don't see how this could work? And it also get's quite messy if we create a shared HTTP profile with Websocket enabled in the /Common/Shared partition, then we would need to include the Common partition in all our application/partition specific AS3 declarations, and that's not a wanted scenario.

Instead we are referencing the /Common/Shared resources such as { "bigip": "/Common/Shared/xxx" } and then I suppose it won't work to include

            "service": {
                "class": "Service_HTTP",
                "virtualPort": 80,
                "virtualAddresses": ["1.2.3.4"],
                "profileHTTP": {
                    "bigip": "/Common/Shared/httpProfileWithWebsockets"
                }
            }

And then in the /Common/Shared partition we would have:

            "httpProfileWithWebsockets": {
                "class": "HTTP_Profile",
                "webSocketsEnabled": true,
                "webSocketMasking": "preserve"
            }

Maybe that would work? I still get confused on how it would know that the VIP needs the WS profile tho. But either way, in short:

• Allow binding of websocket profile to service using bigip notation
• Why? Because we don't want to include the /Common/Shared partition in all our other declarations
• Why not create HTTP profiles in the specific app partition? No, we don't want hundreds of HTTP profiles just to be able to bind websocket profile.

Describe the solution you'd like

Make it possible to assign a websocket profile directly to a service without having an AS3 created HTTP profile. So, just like all other profiles where you can simply use "profileHTTP": { "bigip": "/Path/to/profile" } we would like to have a "profileWebsocket": { "bigip": "/path/to/websocket/profile" }. This is the way it's actually created in the GUI, so I don't really see why it shouldn't be possible to do the same using AS3.

[dstokesf5]

@Eken92 The issues you are experiencing with the use-pointers is related to #313.

In order to improve the experience with using built in http profiles, I have added AUTOTOOL-1888 to our internal product backlog to add a property to reference a websocket profile with a bigip-pointer.

[Eken92]

Is there any update to this? Since there's a possibility to add most other profiles using a regular property I was hoping this wasn't too complicated :) Will it be included in any nearby release? @dstokesf5

Thanks!

[kmaloney]

A few items related to this. There are a few websocket profile config attributes that don't appear to be mapped in AS3 (compress-mode, compression, no-delay and window-bits). Also, websocket profiles can be attached to the virtual with context clientside/serverside (similar to clientTLS/serverTLS). There is an option in the UI for both clientside/serverside websocket profiles to be the same, but the clientside/serverside websocket profiles can also be unique.

[j-zehnder]

Is it possible to get an update on this issue? I am having the same problem

[sunitharonan]

This has been resolved in the 3.40.0 release of AS3.

[Eken92]

This has been resolved in the 3.40.0 release of AS3.

This has not been resolved as my request was to be able to bind an existing websocket profile to a service object/Virtual server (which is actually exactly how you do it using the GUI/rest).

Binding an existing websocket profile to a HTTP profile makes no sense at all, the only thing that has happened is that you've moved the "problem" from one place to another.

[sunitharonan]

We have a similar request and will be prioritizing it in upcoming sprint. Here is the internal product backlog jira id AUTOTOOL-3753