On Mon, Feb 23, 2009 at 2:56 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> I started down the path of adding If: headers to the ra_serf commit-related
> requests, per the HTTP v2 plan. But I quickly noticed that ra_serf's
> delete_entry() implementation already tells the server its caller-provided
> base_revision -- only it doesn't use If: but instead a custom header.
> Interested as to why we do this, I started digging around and eventually
> finally found myself here:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1017#desc11
>
> Are Ben's comments about the problems with using etags and If: accurate? Do
> they present an insurmountable challenge?
>
> When I posed a question about why to use If: and etags instead of a custom
> header in the http-protocol-v2.txt doc, Greg answer it with:
>
> A: Because If-Match is standard HTTP, and proxies can/should
> know about etags to improve the overall performance.
>
> Just jam that base-revision into the etag. In fact, I think
> when mod_dav_svn makes up an etag, it uses that mechanism. ]
>
> I'm not sure I understand the benefit with respect to proxies here, though.
> These are extremely time-sensitive operations against URLs that have
> unique-by-design, temporarily-useful transaction names in them.
I think Greg is proposing we put timeless data into the If: header:
something of the form {repos UUID, rev, path}, which is guaranteed
immutable for all time. This has two benefits, I think:
1. allows us to do an out-of-dateness check on a PUT ("this is base
version of the thing the client thinks it's modifying")
2. it's a standard HTTP header.
I also fail to see how a hypothetical caching-proxy could ever help us
here; I always thought that proxy-caches were about speeding up GET
requests for immutable objects -- I don't see how they'd have anything
to do with a PUT. Regardless, using the 'If' header seems much
cleaner and more standard than our odd X-SVN-Version-Name header, so
I'd like to see the custom header deprecated in the new protocol.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1222114
Received on 2009-02-24 20:33:12 CET