I missed the backstory here: it turns out that OPTIONS wasn't usable
for feature negotiation? I mean, that's what the WebDAV and DeltaV
specs say it's for. Did you end up using custom headers due to a neon
limitation?
On Nov 6, 2007 2:13 AM, Karl Fogel <kfogel@red-bean.com> wrote:
> Issue #2991 is fixed now (see r27590 and r27613, merged to trunk in
> r27614). However, a few things remain unresolved:
>
> 1) Questionable HTTP header extension:
>
> In order to transmit capabilities over HTTP, I've had to add a
> new header (actually, it's repeated, once for each capability)
> to each request. I'm not sure how else to do it; overloading
> "User-Agent:" seemed like a bad idea. There's a long comment in
> subversion/libsvn_ra_neon/util.c:svn_ra_neon__request_dispatch()
> with details, but basically, the new header is called:
>
> "X-SVN-Capabilities:"
>
> Stop right there -- I know what you're thinking! :-) Yes, this
> is not RFC 822 and that header name is going to have to change.
> I'm not sure what to change it to, though. Does anyone have
> experience with the relevant parts of RFC 2774? It's a little
> hard to tell from that document exactly how extension headers
> are done; RFCs seem pretty adamant about never showing examples.
>
> 2) Bidirectional capabilities or not?
>
> Right now, we're transmitting every capability bidirectionally.
> That's "log-revprops", "mergeinfo", and "depth". But the only
> one the server actually *needs* to hear from the client is
> "mergeinfo", which the client doesn't need to hear from the
> server. The other two are the other way around: client wants to
> hear them from server, but server doesn't need them from client.
>
> Should we transmit every capability both ways, or should we make
> capabilities directional: only transmit a capability to a
> consumer that we know is likely to be interested in it?
>
> I lean toward the former, because it's more forward-compatible.
> If in the future one side suddenly starts needing to know a
> partner's capability, the capability at least stands a chance of
> already being available, so we can spare people a minor version
> upgrade.
>
> 3) RA-dependent inconsistency in capability reporting.
>
> This is a minor nit, sort of related to (2). Both ra_local and
> ra_dav (neon and serf) pass the same set of capabilities to
> 'start-commit', namely "log-revprops,depth,mergeinfo" (the order
> might change, but the set is the same). However, ra_svn sends:
>
> "edit-pipeline,svndiff1,absent-entries,depth,mergeinfo,log-revprops"
>
> You can imagine why: it's largely an accident of implementation
> and the fact that ra_svn was already transmitting capabilities
> before the other RA layers got into the game.
>
> Should we filter out the strange ones, or just pass them along
> faithfully? The new documentation in start-commit.tmpl is
> pretty clear on what's guaranteed and what's not, so there
> shouldn't be a correctness issue here. But there may be a
> confusion issue. Thoughts?
>
> Thanks,
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 6 13:48:58 2007