[
https://issues.apache.org/jira/browse/TINKERPOP-2015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16623801#comment-16623801
]
ASF GitHub Bot commented on TINKERPOP-2015:
-------------------------------------------
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/928
Yes, that should be possible. With this PR, you can provide a delegate to
configure the ClientWebSocketOptions which should also include custom headers.
> Allow users to configure the WebSocket connections
> --------------------------------------------------
>
> Key: TINKERPOP-2015
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2015
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
> Affects Versions: 3.3.3, 3.2.9
> Reporter: Florian Hockmann
> Assignee: Florian Hockmann
> Priority: Major
>
> Gremlin.Net currently just creates instances of the {{ClientWebSocket}} class
> with default options. That is probably appropriate for most users but it
> makes it impossible to change the config and use certain features like client
> certificates or proxy settings.
> We could simply allow users to provide a
> [{{ClientWebSocketOptions}}|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions]
> object. Since it's part of .NET Standard (and not a 3rd party library) it
> shouldn't be a problem to expose this type. This would also have the nice
> advantage that users could immediately use new options like the
> {{[RemoteCertificateValidationCallback|https://docs.microsoft.com/dotnet/api/system.net.websockets.clientwebsocketoptions.remotecertificatevalidationcallback]}}
> that was just added in .NET Core 2.1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
