On Sat, Apr 4, 2015 at 11:48 PM, Ben Reser <ben_at_reser.org> wrote:
...
> This isn't about lock validation. I already added a flag to mod_dav's request
> validation to say not to validate locks on the COPY source. Doing the lock
> validation on the COPY source was flat out wrong in generic DAV as well as
> SVN's usage of DAV. The problem is that mod_dav's code to validate ETag's in
> If statements is (unfortunately) intertwined with the locks. Since mod_dav's
> interface to validate locks walks the tree to discover the locks this means
> that validating the ETag's also walks the tree (which is itself probably
> suboptimal but that's another issue for another day).
Ah I see. I was starting to worry that PR54610 [1] also fixed some
wrong behavior applicable to SVN (lock token validation), but now I
understand that is not the case. This is all a side-effect of fixing
the code for ETag's (which needed fixing for COPY, hence the patch),
the logic of which unfortunately was intertwined with lock validation
(not needed for COPY, but part of the deal with the current code) --
and both of them work the same way, by crawling the tree.
> My long term plan is for the request validation is to behave as follows:
>
> Walk the If headers and validate any ETags and then remove them from the list
> of If headers. Ultimately leaving only lock tokens in the list of If headers
> to handle.
>
> If lock validation is required then handle that as we do today. Which will
> ultimately be skipped on the COPY source.
>
> This means that mod_dav's protocol support is intact without any additional
> cost to SVN. No flags or options are required. It just works. Because SVN
> never sends ETags.
That sounds like the perfect solution. I'm afraid I can't help much in
practice ... I can only cheer you on with this :-).
> mod_dav used to ignore ETags on the COPY source, but someone submitted a patch
> to the httpd project, which got applied to fix this. Meaning it's important to
> someone for them to spend the time to fix it. They were using mod_dav_fs. So
> I'm not inclined to break their improvement.
Ack.
>> Also, as hinted by someone else: how strict do we in mod_dav_svn have
>> to follow the dav spec (to act like a law-abiding dav implementation)?
>> Didn't we already take steps away from that by implementing our http
>> v2 protocol?
>
> mod_dav_svn needs to stay a fully valid DAV server. This is actually an
> advertised feature of Subversion. It's probably not a very commonly used
> feature but it is one that we advertise. There are many generic DAV clients
> out there (OS X can mount a DAV server as a file system, various Microsoft
> products can talk directly to them, etc...)
>
> What mod_dav_svn is not advertised is as a generic DeltaV server (which is an
> additional layer on top of DAV). Our protocol changes with http v2 were to
> diverge from the official DeltaV specification. We never promised anyone that
> we'd continue to adhere strictly to DeltaV.
>
> To the best of my knowledge there is almost no interoperable DeltaV software
> out there. I haven't actually tried but I don't think Cadavear can really be
> used as a SVN client and I'm certain you can't use SVN against the only other
> DeltaV server (Oberon) that exists.
I understand now, thanks for clarifying that. It's the DeltaV
extensions that we dropped support for with http v2, but DAV
definitely needs to stay.
> Despite all of that, we actually do have to continue to support the original
> protocol implementation (that as far as I'm aware of is precisely DeltaV)
> because we have SVN clients in the wild that only talk that protocol.
>
> So no I don't think we can just ignore the protocol.
Ack. As long as we produce 1.x servers, we need to keep the http v1
protocol (with DeltaV) working.
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=54610
--
Johan
Received on 2015-04-05 10:10:56 CEST