Sorry if this has been answered elsewhere. But what is the rationale behind
Connect explicitly escaping ' " and / when used in connector names? Shouldn't
that be handled by percent-encoding when using REST endpoints?
best,
Colin
On Fri, Jan 26, 2018, at 10:21, Sönke Liebau wrote:
> I spent s
I spent some time with the code today to try and hit the Jan 30th deadline
for 1.1.
I'm not entirely done yet, there is one weird test failure thst I need to
investigate, but I expect to be able to commit a new version sometime
tomorrow.
However, I just wanted to describe the current behavior of th
I've updated the KIP to prohibit using control characters is connector
names - will create a vote thread tomorrow unless I hear back on
necessary changes from anybody.
Current proposal is to ban all control characters including newline
etc. as well as their escape sequences. I have not specificall
Hi everybody,
I was out of touch for personal reasons the entire week, apologies.
I'll update the KIP tonight and kick of a vote tomorrow morning if no
one objects until then. That gives a little less than two full days
for voting until the deadline kicks in - might work out if everybody
is happy
Sonke,
Have you had a chance to update the KIP and kick off a VOTE thread? We need
to do this ASAP if we want this to make the KIP deadline for 1.1, which is
Jan 23!
On Tue, Jan 16, 2018 at 10:33 PM, Ewen Cheslack-Postava
wrote:
> Sonke,
>
> I'm fine filtering some control characters. The trimm
Sonke,
I'm fine filtering some control characters. The trimming also seems like it
might be *somewhat* moot because the way connector names work in standalone
mode is limited by ConfigDef, which already does trimming of settings. Not
a great reason to be restrictive, but we'd partly just be codify
On Fri, Jan 12, 2018, at 08:03, Sönke Liebau wrote:
> Hi everybody,
>
> from reading the discussion I understand that we have two things still
> open for discussen.
>
> Ewen is still a bit on the fence about whether or not we trim
> whitespace characters but seems to favor not doing it due to th
Hi everybody,
from reading the discussion I understand that we have two things still
open for discussen.
Ewen is still a bit on the fence about whether or not we trim
whitespace characters but seems to favor not doing it due to there not
being a real issue with them. I think it mostly boils down
great point, I'm always for exclusions where they make sense. i just prefer
to include by default w/ exclusions when necessary to listing explicit
inclusions and being restrictive. (and security updates immediately as
needed).
If you have a set of characters you think we should exclude, I think it
On Sat, Jan 6, 2018, at 16:00, Ewen Cheslack-Postava wrote:
> re: whitespace characters, I'm fine with the restriction since I don't see
> it becoming an issue in practice. I just don't see any reason to restrict
> it so it seems like we're going out of our way and doing extra work to be
> restrict
So are we ready to start a vote on this KIP?
On Sat, Jan 6, 2018 at 6:00 PM, Ewen Cheslack-Postava
wrote:
> re: whitespace characters, I'm fine with the restriction since I don't see
> it becoming an issue in practice. I just don't see any reason to restrict
> it so it seems like we're going out
re: whitespace characters, I'm fine with the restriction since I don't see
it becoming an issue in practice. I just don't see any reason to restrict
it so it seems like we're going out of our way and doing extra work to be
restrictive, but without clear motivation.
In general my default approach (
Sönke, I'm happy with the current proposal.
Ewen, the proposal allows any characters in the name as long as they are
properly escaped/encoded. That seems to adhere to the robustness principle.
The only exception is that the proposal trims leading and trailing
whitespace characters in an attempt to
Very late to the game here, but a few thoughts:
1. Regarding whether KIP is necessary, I don't mind doing it for
documentation sake, but I would classify any mishandling of connector names
here as a bug. Which doesn't require a KIP to fix.
2. For support of characters, Kafka has some history of j
@Randall: are you happy with the KIP as it stands so I can call for a vote,
or are there any outstanding items still to discuss?
Same question to anybody else who'd like to participate of course :)
On Thu, Nov 16, 2017 at 5:35 PM, Sönke Liebau
wrote:
> Sounds good. I've added a few sentences to
Sounds good. I've added a few sentences to this effect to the KIP.
On Thu, Nov 16, 2017 at 5:02 PM, Randall Hauch wrote:
> Nice job updating the KIP. The PR (
> https://github.com/apache/kafka/pull/2755/files) for the proposed
> implementation does prevent names from being empty, and it trims wh
Nice job updating the KIP. The PR (
https://github.com/apache/kafka/pull/2755/files) for the proposed
implementation does prevent names from being empty, and it trims whitespace
from the name only when creating a new connector. However, the KIP's
"Proposed Change" section should probably be very cl
I've added some more detail to the KIP [1] around current scenarios that
might break in the future. I actually came up with a second limitation that
we'd impose on users and also documented this.
Let me know what you think.
Kind regards,
Sönke
[1]
https://cwiki.apache.org/confluence/display/KAFK
Hi Randall,
I had mentioned this edge case in the KIP, but will add some further detail
to further clarify all changing scenarios post pull request.
Kind regards,
Sönke
On Thu, Nov 16, 2017 at 2:06 PM, Randall Hauch wrote:
> No, we need to keep the KIP since we want to change/correct the e
No, we need to keep the KIP since we want to change/correct the existing
behavior. But we do need to clarify in the KIP these edge cases that will
change.
Thanks for the continued work on this, Sönke.
Regards,
Randall
> On Nov 16, 2017, at 1:56 AM, Sönke Liebau
> wrote:
>
> Hi Randall,
>
Hi Randall,
zero length definitely works, that's what sent me down this hole in the
first place. I had a customer accidentally create a connector without a
name in his environment and then be unable to delete it. No connector name
doesn't work, as this throws a null pointer exception due to KAFKA-
Thanks for updating the KIP to reflect the current process. However, I
still question whether it is necessary to have a KIP - it depends on
whether it was possible with prior versions to have connectors with
zero-length or blank names. Have you tried both of these cases?
On Fri, Nov 10, 2017 at 3:
Hi Randall,
I have set aside some time to work on this next week. The fix itself is
quite simple, but I've yet to write tests to properly catch this, which
turns out to be a bit more complex, as it needs a running restserver which
is mocked in the tests I've looked at so far.
Should I withdraw th
Any progress on updating the PR and withdrawing KIP-212?
On Fri, Oct 27, 2017 at 5:19 PM, Randall Hauch wrote:
> Yes, connector names should not be blank or contain just whitespace. In
> fact, I might recommend that we trim whitespace at the front and rear of
> new connector names and then disal
Yes, connector names should not be blank or contain just whitespace. In
fact, I might recommend that we trim whitespace at the front and rear of
new connector names and then disallowing any zero-length name. Existing
connectors would remain valid, and this would not break backward
compatibility. Th
On Wed, Oct 25, 2017, at 01:07, Sönke Liebau wrote:
> I've spent some time looking at this and testing various characters and
> it
> would appear that Randall's suspicion was spot on. I think we can support
> a
> fairly large set of characters with very minor changes.
>
> I was put of by the excep
I've spent some time looking at this and testing various characters and it
would appear that Randall's suspicion was spot on. I think we can support a
fairly large set of characters with very minor changes.
I was put of by the exceptions that were thrown when creating connectors
with certain chara
On Tue, Oct 24, 2017, at 11:28, Sönke Liebau wrote:
> Hi,
>
> after reading your messages I'll grant that I might have picked a
> somewhat
> draconic option to solve these issues.
>
> In general I believe that properly encoding the URLs after having created
> the connectors should solve a lot of
Hi,
after reading your messages I'll grant that I might have picked a somewhat
draconic option to solve these issues.
In general I believe that properly encoding the URLs after having created
the connectors should solve a lot of the issues already. For some
characters the rest api returns an erro
It should be possible to use entity references to encode these
characters in URLs. See https://dev.w3.org/html5/html-author/charref
Maybe I'm misunderstanding the problem, but can we simply encode the
URLs, rather than restricting the names?
best,
Colin
On Mon, Oct 23, 2017, at 14:12, Randall
Here's the link to KIP-212:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74684586
I do think it's worthwhile to define the rules for connector names.
However, I think it would be better to describe the current restrictions
for names outside of them appearing within URLs. For ex
All,
I've created a KIP to discuss enforcing of rules on what characters are
allowed in connector names.
Since this may break api calls that are currently working I figured a KIP
is the better way to go than to just create a jira.
I'd love to hear your input on this!
32 matches
Mail list logo
