[
https://issues.apache.org/jira/browse/CASSPYTHON-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127402#comment-18127402
]
Bohdan Siryk edited comment on CASSPYTHON-29 at 10/15/26 8:10 AM:
------------------------------------------------------------------
> An additional question: if we knew that system_views.clients was very
> diligent about not printing control characters (or other unprintable content)
> would we even be having this discussion? It seems like that's where the focus
> should be rather than what the clients are sending.
As [~bschoeni] said above, startup options also reach _nodetool clientstats
--client-options_ and unprintable characters polutes its output and may result
in a breaking of some parsing tools if unprintable / control characters are
supplied. I already tested it before and I confirm that output might have
unreadble chars.
> On the spec point: it does say strings are UTF-8, but the STARTUP section
> reads “T{_}he body is a [string map] of options. Possible options are: …{_}”
> followed by a fixed list. That phrasing reads to me like an enumeration of
> defined keys rather than an open-ended map with {{APPLICATION_NAME}} and
> {{APPLICATION_VERSION}} treated as undocumented additions to it.
By reading the history of CASSANDRA-16378 I'm getting an impression that we are
free to put in the the map whatever we want actually. Probably, it would be
better if the spec explicitly say this and how such custom key-pairs should be
formatted. There is http x-headers mentioned, so what if we add a prefix to our
custom options like _client_id ->_ _x_client_id._ This will solve the concern
of coliding server / client side options. But I'm unsure if we should enforce
it on a client side? Or just documenting it in both protocol spec and the
client saying it is a good practice to do x because of y.
> So before we expose arbitrary parameters, I’d suggest the server be hardened
> to constrain the STARTUP
I'm not opossed to such changes on the server, but I want to hightlight the
driver still might be used to connect to servers that do not support such
constraints
was (Author: JIRAUSER313157):
> An additional question: if we knew that system_views.clients was very
> diligent about not printing control characters (or other unprintable content)
> would we even be having this discussion? It seems like that's where the focus
> should be rather than what the clients are sending.
As [~bschoeni] said above, startup options also reach _nodetool clientstats
--client-options_ and unprintable characters polutes its output and may result
in a breaking of some parsing tools if unprintable / control characters are
supplied. I already tested it before and I confirm that output might have
unreadble chars.
> On the spec point: it does say strings are UTF-8, but the STARTUP section
> reads “T{_}he body is a [string map] of options. Possible options are: …{_}”
> followed by a fixed list. That phrasing reads to me like an enumeration of
> defined keys rather than an open-ended map with {{APPLICATION_NAME}} and
> {{APPLICATION_VERSION}} treated as undocumented additions to it.
By reading the history of CASSANDRA-16378 I'm getting an impression that we are
free to put in the the map whatever we want actually. Probably, it would be
better if the spec explicitly say this and how such custom key-pairs should be
formatted. There is http x-headers mentioned, so what if we will add some sort
of a prefix to our custom options like _client_id ->_ _x_client_id._ This will
solve the concern of coliding server / client side options. But I'm unsure if
we should enforce it on a client side? Or just documenting it in both protocol
spec and the client saying it is a good practice to do x because of y.
> So before we expose arbitrary parameters, I’d suggest the server be hardened
> to constrain the STARTUP
I'm not opossed to such changes on the server, but I want to hightlight the
driver still might be used to connect to servers that do not support such
constraints
> Allow user to specify arbitrary parameters for STARTUP message
> --------------------------------------------------------------
>
> Key: CASSPYTHON-29
> URL: https://issues.apache.org/jira/browse/CASSPYTHON-29
> Project: Apache Cassandra Python driver
> Issue Type: Improvement
> Components: Core
> Reporter: Swathi Sekar
> Assignee: Bohdan Siryk
> Priority: Normal
> Fix For: 4.0.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Modify the driver to allow sending arbitrary STARTUP message options.
> Proposed design:
> - Add `extra_startup_options` param to Cluster constructor.
> - Thread it through Cluster -> connection setup (cluster.py) ->
> StartupMessage.
> - Define clear precedence/conflict behavior when duplicate/conflicting
> options are passed into the StartupMessage constructor.
> *Note:*
> This Jira was originally created for sending the client's application name
> and version as `APPLICATION_NAME` /
> `APPLICATION_VERSION` options in the STARTUP message, which is tied to the
> now-defunct DataStax Insights offering.
> Since the Java driver (5.0.0) and eventually C/C++ driver (3.0.0) are
> removing withApplicationName()/withApplicationVersion() entirely, this ticket
> has been updated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
