You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@wandisco.com> on 2011/03/07 15:36:08 UTC
HTTPv2 question - eliminate stub URLs in OPTIONS response?
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?
The proposed extension to support client-specified transaction names
involves adding "vtxn" and "vtxr" to this group of URL stubs, and that
made me wonder whether transmitting this group of headers is actually
serving a useful purpose.
I guess the data and processing time overhead for using these headers is
negligible as it's only once per connection, so this comes down to being
a small design simplification, eliminating the need to process and cache
these things individually. Is it just not worth worrying about because
we have to cache something anyway (the "!svn" part)? Or do the final
components of those stubs have to be configurable for some technical
reason, even though we'll only ever use them if the server indicates
that it supports them?
Just wondering what the designers think.
- Julian
Re: HTTPv2 question - eliminate stub URLs in OPTIONS response?
Posted by Julian Foad <ju...@wandisco.com>.
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
Re: HTTPv2 question - eliminate stub URLs in OPTIONS response?
Posted by Greg Stein <gs...@gmail.com>.
On Mon, Mar 7, 2011 at 14:41, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Mon, Mar 7, 2011 at 9:34 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> 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.
>
> +1. -- justin
Agreed!
Cheers,
-g
Re: HTTPv2 question - eliminate stub URLs in OPTIONS response?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Mar 7, 2011 at 9:34 AM, C. Michael Pilato <cm...@collab.net> wrote:
> 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.
+1. -- justin
Re: HTTPv2 question - eliminate stub URLs in OPTIONS response?
Posted by "C. Michael Pilato" <cm...@collab.net>.
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand