You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2004/10/18 18:10:54 UTC
Re: certain property names cause non-wf XML responses
Ben Reser <be...@reser.org> writes:
> We've been down this road before. I'll be so bold to say that you're
> wasting your time and that I'm probably going to -1 (veto) any proposal
> you have. Here's why...
Then you're going to get a vote on that veto, if it comes to that :-).
(But you saw when I filed the issue... Perhaps you were just waiting
until you saw some action, which is understandable.)
> First and foremost this problem is the greatest for non-svn client
> implementations (i.e. DAV clients). These clients may be using XML
> parsers that enforce the XML namespace recommendations. This is
> unfortunate but understandable.
Yep, I know.
> Any method of fixing this requires encoding. Because property names are
> passed as XML elements there is no way to encode the data such that a
> valid XML parser will automatically decode it for us. This means that
> we must encode our data before generating the XML and then decode it in
> the client after the XML parser is done.
Right.
> Let's consider that we have 3 classes of clients we need to support with
> this change:
>
> * Old SVN clients that don't know about encoding of property names.
> * New SVN clients thta do know about encoding of property names.
> * DAV clients that know nothing about SVN.
Right.
> Currently, we have no way of separating a SVN client from a generic DAV
> client. In order to fix the DAV clients that dislike our XML we'd need
> to be sure to encode for them. However, if we encode properties for
> them we'd also be encoding for the old SVN clients that don't know
> anything about encoding of properties.
Right.
> In the past you've said that would be okay, they'd just get a property
> name that is different. But this is a compatability breakage. If
> talking to a 1.2 SVN DAV server makes svk:foo show up as some other name
> then existing SVK clients will break due to not seeing their property
> names. This would force all SVK users to upgrade to newer versions of
> SVK (or use a newer version of the bindings that know about the
> encoding) because the server was upgraded.
No, in the past I've said (or meant to say) that this fix needs to be
deployed using compatibility stages, and that it's important to roll
out the first stage -- the ability to decode these encodings -- as
soon as possible.
> As a result you can't fix the encoding problem for the only people it is
> creating a problem for (a small minority at that), the DAV clients.
> Without breaking our compatability with old SVN clients (a much larger
> group).
Grrrr :-).
Why don't you wait to see the proposal and then talk about it?
> Given that very few people have run into this issue. I think we have
> much more important things to worry about than this. Until 2.0 I think
> our only course of action is to discourage people from using colons in
> property names. Once 2.0 comes along we can break client
> interoperability and start encoding property names as you suggest.
Simply discouraging use of colons in property names is unacceptable to
me. Colons are the first and most obvious character people think of
when they need a namespace-ish separator. It was the first choice for
svk, it was the first choice for cvs2svn, and it would be the first
choice for anyone else. They're just following the lead suggested by
Subversion itself with our "svn:" properties.
Subversion properties were explicitly meant to allow colons since Day
One. This policy has never changed. A transport layer bug does not
constitute a change of policy, and a certain (minimal) degree of
compatibility pain may even be tolerable to fix such a major bug.
I am working on as thorough a proposal as I can come up with. It will
try to minimize compatibility problems. I think you're right that
there may still be some compatibility problems, but then it will just
be a question of which bug is worse.
And the answer to that question is *not* automatically "Compatibility
is always more important than any loss of functionality". This bug is
a loss of functionality, functionality which is quite user-visible and
which was documented to be in Subversion all along. We have a
cost/benefit analysis to make, and there is no automatically right
answer.
At bottom, I don't really understand why you think it's okay to not
allow colons in property names. Plenty of people want to do it, and
we always meant to support it.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: certain property names cause non-wf XML responses
Posted by kf...@collab.net.
Julian Reschke <ju...@gmx.de> writes:
> > I think your custom-report solution also lessens the urgency of
> > #1971,
> > because there aren't any important compatibility stages. We can add
> > the feature to client and server simultaneously, and each would retain
> > the ability to work the old way when faced with an older interlocutor.
> > The only thing with compatibility implications is for the server to
> > stop sending DAV-incompatible props over DAV. But as there's no
> > corresponding client change to that, it's simply a one-time thing that
> > we do at 2.0 (but not before, of course, because it would break 1.x
> > client compatibility).
> > Sanity check: does the above make sense?
>
> Yes. But keep in mind that changes in the neon lib may be upcoming
> which would force you to do that change earlier; quoting Joe from
> <http://subversion.tigris.org/issues/show_bug.cgi?id=1807>:
Sure, we can make that decision if/when it becomes necessary.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: certain property names cause non-wf XML responses
Posted by Julian Reschke <ju...@gmx.de>.
kfogel@collab.net wrote:
> Agreed.
>
> I think your custom-report solution also lessens the urgency of #1971,
> because there aren't any important compatibility stages. We can add
> the feature to client and server simultaneously, and each would retain
> the ability to work the old way when faced with an older interlocutor.
>
> The only thing with compatibility implications is for the server to
> stop sending DAV-incompatible props over DAV. But as there's no
> corresponding client change to that, it's simply a one-time thing that
> we do at 2.0 (but not before, of course, because it would break 1.x
> client compatibility).
>
> Sanity check: does the above make sense?
Yes. But keep in mind that changes in the neon lib may be upcoming which
would force you to do that change earlier; quoting Joe from
<http://subversion.tigris.org/issues/show_bug.cgi?id=1807>:
"------- Additional comments from Joe Orton Thu Mar 25 15:04:47 -0700
2004 -------
Julian Reschke brought this up a while back: it's a "don't do that"
issue rather than an escaping issue. The element names being used are
not valid according to the XML Namespaces spec:
"<svk:signature xmlns="http://..."/>"
and indeed mod_dav has no choice but to reject that request. neon 0.25
and later will also reject responses which include these invalid elements."
Best regards, Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: certain property names cause non-wf XML responses
Posted by kf...@collab.net.
Ben Reser <be...@reser.org> writes:
> On Mon, Oct 18, 2004 at 03:30:03PM -0500, kfogel@collab.net wrote:
> > If we discourage them from using colons, I think they're experiencing
> > pain (all "svk:" users, for example?).
>
> They are? Where? Since I added the workaround nobody has had any
> issues with coloned properties within the context of using our libs.
> Which includes SVK. The only way anyone would be having any problems is
> if they're mixing using SVK and generic DAV clients. Which I suspect is
> pertty rare. If it wasn't clkao would have switched to something like
> svk.foo by now.
Ah, what I meant was, if we discourage them from using colons, then
*if they take our advice*, they'll experience pain. Right now they're
not experiencing, pain. But that's because they get to use colons.
> Anyway you've posted an alternate solution I've come up with on Issue
> #1971. So this thread is pretty much dead at this point.
Agreed.
I think your custom-report solution also lessens the urgency of #1971,
because there aren't any important compatibility stages. We can add
the feature to client and server simultaneously, and each would retain
the ability to work the old way when faced with an older interlocutor.
The only thing with compatibility implications is for the server to
stop sending DAV-incompatible props over DAV. But as there's no
corresponding client change to that, it's simply a one-time thing that
we do at 2.0 (but not before, of course, because it would break 1.x
client compatibility).
Sanity check: does the above make sense?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: certain property names cause non-wf XML responses
Posted by Ben Reser <be...@reser.org>.
On Mon, Oct 18, 2004 at 03:30:03PM -0500, kfogel@collab.net wrote:
> If we discourage them from using colons, I think they're experiencing
> pain (all "svk:" users, for example?).
They are? Where? Since I added the workaround nobody has had any
issues with coloned properties within the context of using our libs.
Which includes SVK. The only way anyone would be having any problems is
if they're mixing using SVK and generic DAV clients. Which I suspect is
pertty rare. If it wasn't clkao would have switched to something like
svk.foo by now.
Anyway you've posted an alternate solution I've come up with on Issue
#1971. So this thread is pretty much dead at this point.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: certain property names cause non-wf XML responses
Posted by kf...@collab.net.
Ben Reser <be...@reser.org> writes:
> Yes that's true, which is part of the reason I suggested that we
> discourage their use. I'm adopting Greg Hudson's attitude on issues
> like this. Let's worry about it when we go down that road.
>
> If we fix it now we know we'll be creating inconvience for people to
> save them from a potential inconvience later, which may never happen.
>
> I think it's going to be hard to explain to users why we're breaking
> their apps (which we promised we wouldn't) when the reason we are giving
> for doing it is to fix a bug that they're not experiencing any pain
> from.
If we discourage them from using colons, I think they're experiencing
pain (all "svk:" users, for example?).
> If at some point the XML parsers get stricter I imagine the following
> will happen. A small group of people will be early adopters of the new
> library versions. We tell them to revert to a previous version for the
> time being. We take the painful option of breaking compatability at the
> next minor release, which we'll probably move up to release ASAP to deal
> with this.
>
> My biggest priority is trying to keep this bug out of peoples faces. At
> this point it's a correctness issue. If and when my workaround fails to
> hold I'll support any compatability breaks needed to fix the problem.
That may be a good strategy, must mull it over. In the meantime, the
meat of my proposal is the decoding scheme, which we want to get in
ASAP anyway, so I'll continue working.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: certain property names cause non-wf XML responses
Posted by Ben Reser <be...@reser.org>.
On Mon, Oct 18, 2004 at 02:28:23PM -0500, kfogel@collab.net wrote:
> Here's why I'm worried:
>
> Aren't we also depending on Subversion's XML parser remaining loose
> for the rest of the 1.x line, when in fact that would be hard for us
> to guarantee that it remain that loose -- because it comes from an
> external library that we might want to upgrade for other reasons?
>
> Thus the issue is that even Subversion isn't safe for these properties
> in the long term. That's why I think this issue is important now.
Yes that's true, which is part of the reason I suggested that we
discourage their use. I'm adopting Greg Hudson's attitude on issues
like this. Let's worry about it when we go down that road.
If we fix it now we know we'll be creating inconvience for people to
save them from a potential inconvience later, which may never happen.
I think it's going to be hard to explain to users why we're breaking
their apps (which we promised we wouldn't) when the reason we are giving
for doing it is to fix a bug that they're not experiencing any pain
from.
If at some point the XML parsers get stricter I imagine the following
will happen. A small group of people will be early adopters of the new
library versions. We tell them to revert to a previous version for the
time being. We take the painful option of breaking compatability at the
next minor release, which we'll probably move up to release ASAP to deal
with this.
My biggest priority is trying to keep this bug out of peoples faces. At
this point it's a correctness issue. If and when my workaround fails to
hold I'll support any compatability breaks needed to fix the problem.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: certain property names cause non-wf XML responses
Posted by kf...@collab.net.
Ben Reser <be...@reser.org> writes:
> Well actually you didn't file the issue. I milestoned it to 2.0 and
> then didn't see you change it to 1.2 or I would have objected then.
> Probably happened with a bunch of other milestones and I read right past
> it.
Whups -- yes, I meant "milestoned".
> Old clients failing to unquote it as you state above is a failure of our
> compatability guarantees. We know there are popular programs using
> property names with colons in them.
>
> That said your proposal for adding the decoding scheme is fine if you
> work with the following time frame:
>
> 1.x clients gain the ability to decode the property names.
> 2.x servers encode the property names.
>
> That's fine. But it doesn't really fix the issue earlier which is what
> your stated goal is. It just helps with our compatability for 1.x
> clients with 2.x servers when we do fix this. Which may or may not
> matter in the future, depending on other changes. Not that I'd object
> to adding the decoding as early as possible to help offset that
> compatability issue.
>
> However, even if we add the decoding scheme now, the bug will not be
> closed until 2.0. So your 1.2 milestone is wrong.
It's only wrong if one accepts that it cannot be solved before 2.0,
which is what we're discussing.
(Note also that sometimes we put a multi-stage issue in the first
relevant milestone, with a note to bump to a later one when the first
stage is fixed, and so on. Not that that's what I intended here.)
> Because you haven't sent it and I can't see how you're going to
> fix the problem until 2.0 without breaking compatability in a completely
> unacceptable way. As a result I'd rather see you spend your time on
> more important things.
Fair enough -- I can't really argue with that answer :-).
> This is a really unfair response. I'm responding on the basis of that
> cost benefit analysis. Our clients are perfectly functional with
> coloned names currently. The only issue is with other DAV clients that
> enforce the XML namespace rules. This is unfortunate, but we already
> know other areas where we're not compatable with DAV clients fully.
> That said, I don't think DAV compatablity should ever come before SVN
> client compatability. If we have to break SVN clients for DAV clients
> to work that's not a tradeoff I'm willing to make.
Here's why I'm worried:
Aren't we also depending on Subversion's XML parser remaining loose
for the rest of the 1.x line, when in fact that would be hard for us
to guarantee that it remain that loose -- because it comes from an
external library that we might want to upgrade for other reasons?
Thus the issue is that even Subversion isn't safe for these properties
in the long term. That's why I think this issue is important now.
Sorry to have attributed to ignorance what can be adequately explained
by merely different priorities. I do realize that you don't like the
current situation either, didn't mean to imply otherwise.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: certain property names cause non-wf XML responses
Posted by Ben Reser <be...@reser.org>.
On Mon, Oct 18, 2004 at 01:10:54PM -0500, kfogel@collab.net wrote:
> Then you're going to get a vote on that veto, if it comes to that :-).
>
> (But you saw when I filed the issue... Perhaps you were just waiting
> until you saw some action, which is understandable.)
Well actually you didn't file the issue. I milestoned it to 2.0 and
then didn't see you change it to 1.2 or I would have objected then.
Probably happened with a bunch of other milestones and I read right past
it.
> No, in the past I've said (or meant to say) that this fix needs to be
> deployed using compatibility stages, and that it's important to roll
> out the first stage -- the ability to decode these encodings -- as
> soon as possible.
Actually this is what you said in the past (from msgid
<85...@newton.ch.collab.net> which can be found at
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=72323 )
> With this enhancement, anytime someone sets a property whose name
> contains special characters, we transform it into
> "svn:quoted-propname:<quoted-str>" for transport. In the actual
> working copy, and in the repository, it does not need the quoting,
> because our storage formats there can handle the real names. However,
> if an older repository happens to keep the quoting, that's okay! Old
> clients will simply fail to unquote it; new clients will correctly
> unquote it. No one will crash, and all information will be preserved
> in one of two possible forms, until eventually everyone is upgraded."
Old clients failing to unquote it as you state above is a failure of our
compatability guarantees. We know there are popular programs using
property names with colons in them.
That said your proposal for adding the decoding scheme is fine if you
work with the following time frame:
1.x clients gain the ability to decode the property names.
2.x servers encode the property names.
That's fine. But it doesn't really fix the issue earlier which is what
your stated goal is. It just helps with our compatability for 1.x
clients with 2.x servers when we do fix this. Which may or may not
matter in the future, depending on other changes. Not that I'd object
to adding the decoding as early as possible to help offset that
compatability issue.
However, even if we add the decoding scheme now, the bug will not be
closed until 2.0. So your 1.2 milestone is wrong.
> Grrrr :-).
> Why don't you wait to see the proposal and then talk about it?
Because you haven't sent it and I can't see how you're going to
fix the problem until 2.0 without breaking compatability in a completely
unacceptable way. As a result I'd rather see you spend your time on
more important things.
> Simply discouraging use of colons in property names is unacceptable to
> me. Colons are the first and most obvious character people think of
> when they need a namespace-ish separator. It was the first choice for
> svk, it was the first choice for cvs2svn, and it would be the first
> choice for anyone else. They're just following the lead suggested by
> Subversion itself with our "svn:" properties.
>
> Subversion properties were explicitly meant to allow colons since Day
> One. This policy has never changed. A transport layer bug does not
> constitute a change of policy, and a certain (minimal) degree of
> compatibility pain may even be tolerable to fix such a major bug.
I resolved the major bug. We no longer error on them. The bug is no
relegated to a much smaller minority of our users. See below for more
discussion on discouraging colons...
> I am working on as thorough a proposal as I can come up with. It will
> try to minimize compatibility problems. I think you're right that
> there may still be some compatibility problems, but then it will just
> be a question of which bug is worse.
>
> And the answer to that question is *not* automatically "Compatibility
> is always more important than any loss of functionality". This bug is
> a loss of functionality, functionality which is quite user-visible and
> which was documented to be in Subversion all along. We have a
> cost/benefit analysis to make, and there is no automatically right
> answer.
This is a really unfair response. I'm responding on the basis of that
cost benefit analysis. Our clients are perfectly functional with
coloned names currently. The only issue is with other DAV clients that
enforce the XML namespace rules. This is unfortunate, but we already
know other areas where we're not compatable with DAV clients fully.
That said, I don't think DAV compatablity should ever come before SVN
client compatability. If we have to break SVN clients for DAV clients
to work that's not a tradeoff I'm willing to make.
> At bottom, I don't really understand why you think it's okay to not
> allow colons in property names. Plenty of people want to do it, and
> we always meant to support it.
Ohh come on. I spent several days working through this issue to try and
fix this issue and allow everything we allow currently. This is even
more unfair than above. I've never said it was okay. I don't like it.
But it's reality. I've never once advocated that we disallow colons as
the solution. Rather I've advocated that the solution wait till 2.0.
In the meantime we educate users as to the consequences of using colons
in property names. If the consequences aren't an issue for them then by
all means they should use them if they want.
Discourage != Disallow
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org