[
https://issues.apache.org/jira/browse/CASSPYTHON-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18126873#comment-18126873
]
Bret McGuire edited comment on CASSPYTHON-29 at 10/13/26 10:57 PM:
-------------------------------------------------------------------
Yeah, I think I'm pretty much where it sounds like [~jeremiah] is (although I
definitely don't want to speak for him). If we're concerned about the display
of control characters or other non-printable chars in strings it seems like
that absolutely has to be handled at the server. There are lots of clients out
there (and users are always free to make their own) so we have very little to
zero control over what we'll actually receive from clients. For me it follows
that system_views.clients has to be fairly diligent about checking for
non-ASCII characters if it chooses to do so (perhaps informed by a server-side
policy of some kind) before displaying data... but I don't agree that this
imposes a burden on clients to restrict what data is allowed to be sent.
I take your point (derived from the Copilot review) about warning users that
the contents of the map they submit might be visible to others (including a
specific reference to system_views.clients). But even that Copilot comment
only mentions warning users... and there seems to be a fairly significant
difference between warning a user of some possible data exposure and denying
them access to the ability to set a map of values for STARTUP messages at all.
Finally, I want to emphasize that the specification _explicitly says_ that
strings in the CQL protocol are just UTF-8 strings. There is no constraint
that they be some subset of UTF-8 or conform to any other standard. I would
further argue that if we wish to impose a restriction that goes _beyond_ what's
in the spec we should have a very clear use case for doing so... and it's not
immediately clear to me that we have that here.
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.
was (Author: JIRAUSER304104):
Yeah, I think I'm pretty much where it sounds like [~jeremiah] is (although I
definitely don't want to speak for him). If we're concerned about the display
of control characters or other non-ASCII chars in strings it seems like that
absolutely has to be handled at the server. There are lots of clients out
there (and users are always free to make their own) so we have very little to
zero control over what we'll actually receive from clients. For me it follows
that system_views.clients has to be fairly diligent about checking for
non-ASCII characters if it chooses to do so (perhaps informed by a server-side
policy of some kind) before displaying data... but I don't agree that this
imposes a burden on clients to restrict what data is allowed to be sent.
I take your point (derived from the Copilot review) about warning users that
the contents of the map they submit might be visible to others (including a
specific reference to system_views.clients). But even that Copilot comment
only mentions warning users... and there seems to be a fairly significant
difference between warning a user of some possible data exposure and denying
them access to the ability to set a map of values for STARTUP messages at all.
Finally, I want to emphasize that the specification _explicitly says_ that
strings in the CQL protocol are just UTF-8 strings. There is no constraint
that they be some subset of UTF-8 or conform to any other standard. I would
further argue that if we wish to impose a restriction that goes _beyond_ what's
in the spec we should have a very clear use case for doing so... and it's not
immediately clear to me that we have that here.
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.
> 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]
