[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Mon, 07 Mar 2011 12:34:42 -0500

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.

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

Received on 2011-03-07 18:35:19 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.