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
Received on 2011-03-07 15:36:47 CET