HTTP v2 commit out-of-dateness checks

["C. Michael Pilato" <cm...@collab.net>]

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.  Not the
kind of request that's ever issue more than once across the set of all
clients in the Universe.  As such, they seem like the worse type of
candidate for a cache-served response of the sort any proxy aimed at
performance enhancement might wish to offer.  So I fail to see how the use
of If: and etags truly helps us.  And I wouldn't be pushing the matter if it
weren't the confusing state of the code today.  The server generates etags
like so:

  "REV/path/to/item"               ### etag
  W/"REV/path/to/item"             ### weak version of the etag

but the client doesn't pass that format back to the server in its If:
headers.  It uses If: for lock tokens:

  </path/to/item> (<LOCK-TOKEN>)   ### used for verifying locks

and uses the custom X-SVN-Version-Name: header to transmit base revisions.

Help?

-- C. Michael Pilato
   Asst. to Mr. H. T. Teepee

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1216601

Re: HTTP v2 commit out-of-dateness checks

[Ben Collins-Sussman <su...@red-bean.com>]

On Mon, Feb 23, 2009 at 2:56 PM, C. Michael Pilato <cm...@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