fix(websocket): fix setup logic in the external transport (IDFGH-15250)

[huming2207]

Description

Hi all,

I made a dumb mistake when I was submitting the PR: #573

I somehow forgot two branch logic when setting up the websocket client transport. These two logic exist in our company's codebase and we have used it for a year already, but somehow was missing in the PR to this upstream codebase. Without these two conditions, the websocket client will create a esp_transport handle anyhow, no matter the ext_transport was provided or not. This will break the proxy support of course.

Anyway, here's the fix. Sorry again for the trouble I made.

Regards,
Jackson

Related

PR related:

• feat(websocket): allow using external TCP transport handle (IDFGH-12825) #573
• fix(websocket): don't fetch transport from the list if external transport is set #616

Testing

These two logic exist in our company's codebase and we have used it for a year already in our products.

Checklist

Before submitting a Pull Request, please ensure the following:

• 🚨 This PR does not introduce breaking changes.
• All CI checks (GH Actions) pass.
• Documentation is updated as needed.
• Tests are updated or added as necessary.
• Code is well-commented, especially in complex areas.
• Git history is clean — commits are squashed to the minimum necessary.

[huming2207]

Sorry, we internally reviewed and we think we have more issues to fix. I will fix it first and then let you know we are ready.

[huming2207]

Okay now I'm ready for review.

This also fixes some potential memory corruptions. Previously if I use an externally created proxy handle that is not a transport_ssl or transport_tcp handle, and if some options like keep alive was set, the esp_transport_ssl_set_*() will be called and eventually corrupts the proxy handle context. Because the type is different.

[huming2207]

Hello @glmfe , may I ask is there any feedback on this PR?