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
