[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: HTTPv2 question - eliminate stub URLs in OPTIONS response?

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Mon, 07 Mar 2011 18:00:20 +0000

C. Michael Pilato wrote:
> On 03/07/2011 09:36 AM, Julian Foad wrote:
> > Just a passing question from a non-expert on a possible simplification
> > to the HTTPv2 spec <notes/http-and-webdav/http-protocol-v2.txt>.
> >
> >> * Opening an RA session:
> >>
> >> ra_serf will send an OPTIONS request when creating a new
> >> ra_session. mod_dav_svn will send back what it already sends now,
> >> but will also return new information as custom headers in the
> >> OPTIONS response:
> >>
> >> SVN-Youngest-Rev: REV
> >> SVN-Me-Resource: /REPOS-ROOT/!svn/me
> >> [...]
> >> SVN-Rev-Stub: /REPOS-ROOT/!svn/rev
> >> SVN-Rev-Root-Stub: /REPOS-ROOT/!svn/rvr
> >> SVN-Txn-Stub: /REPOS-ROOT/!svn/txn
> >> SVN-Txn-Root-Stub: /REPOS-ROOT/!svn/txr
> >
> > As I understand it, part of the idea for HTTPv2 is to reduce the need
> > for discovering per-request server-configurable URLs, and allow the
> > client to construct them straight off. The majority of the benefit is
> > in eliminating network round-trips, which it achieves.
> >
> > I just wondered, though, would it make sense to eliminate the SVN-*-Stub
> > URL headers from the OPTIONS response and transmit just the common part
> > of the URLs in a single header, and have the client construct all of
> > them from the common part using hard-coded strings for the last
> > component?
>
> Such an optimization would be beyond negligible, processing- and
> network-usage-wise. And by allowing the server to dictate "This is how you
> need to talk to me" we leave allow ourselves the option of making changes to
> the server's URL-space in a fashion that any HTTPv2-ready client can
> gracefully adjust to.

Thanks Mike.

- Julian
Received on 2011-03-07 19:00:59 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.