Probe using OPTIONS

[Jelmer Vernooij]

Vincent Ladeuil wrote:
>>>>>> "Jelmer" == Jelmer Vernooij <jelmer at samba.org> writes:
>>>>>>             
>
>     Jelmer> Hi Vincent,
>
>     Jelmer> As we discussed during UDS, I'd like to add a
>     Jelmer> mechanism that allows bzr-svn to do an OPTIONS
>     Jelmer> request before the probing of the smart server using
>     Jelmer> a POST request to .bzr/smart hits in.
>
> We talked about that already and Andrew didn't agree and, AIUI,
> this is still the main reason for your friendly fork of bzr.
>   
AFAIK Andrew's argument was about leaving the smart server probe using
POST in place, not against OPTIONS. I'm not suggesting removing the
smart server probe, just about (optionally) doing an OPTIONS request
before the smart server probe.

My friendly fork of Bazaar no longer has the smart server support
disabled, since bzr-svn now inserts itself before the smart server in
the list of supported formats.
>     Jelmer> So far I've done this by moving the bzr-svn check
>     Jelmer> before the bzr smart server one. This is a bit
>     Jelmer> hackish and it also means that the results of the
>     Jelmer> OPTIONS request done by bzr-svn are lost. ISTM the
>     Jelmer> OPTIONS result would also be useful for
>     Jelmer> e.g. bzr-webdav?
>
> Nice try but no cigar :-) I can't see how webdav will use it and
> it would have to be cached at the transport level which we don't
> share AFAIK. But trying to share information about the server
> during the probe sounds like a good idea.
>   
bzr-svn does use the standard http transport a bit, in particular at the
moment to do the OPTIONS request (but only if using urllib). That way we
don't have to open a new TCP connection and sometimes do a SSL handshake
just to find out that the remote server doesn't support Subversion.

WebDAV should be able to use it to find out what versions of DAV are
supported, what extensions, and what HTTP mechanisms.
>     Jelmer> Would it make sense to allow control formats to probe
>     Jelmer> based on the OPTIONS reply ?
>
> I think the whole probe design should be clearly exposed so we
> can start to discuss its pro/cons more generally.
>
> In UDS Andrew seemed convinced that the smart server probe should
> stay in place.
>   
> You clearly have a use case where it breaks the user experience.
>
> The best we can do so far is to introduce some config variable
> (presumably in authentication.conf since it targets remote
> server) to disable the smart server on a case-by-case basis.
>   
That problem we already work around - as I mentioned, I'm now having
bzr-svn do the probe of a remote server before the smart server, and so
if there is a Subversion server remotely we find out before we attempt
to POST to it. If the user is using Pycurl this unfortunately means that
we do an extra TCP connection and possibly an extra SSL handshake for
every (even unrelated) probe over HTTP(s) if bzr-svn is installed.

It would be nice if there was some more appropriate mechanism for this
inside of bzrlib that I could hook into. At the moment it's a bit
hackish and very much specific to urllib.
> I also remember your objections about that approach: even if we
> provide *by default* configurations for some well known servers,
> new ones can (and will) appear.
>
> Both bzr-svn and the smart server want to avoid a useless round-trip.
>
> First I'll note that serverS exist *today* for which that useless
> round-trip won't be avoided with the actualS solutions (for
> bzr-svn OR the smart server).
>
> Things are even more uncomfortable for bzr-svn users since they
> are prompted for credentials even for read-only operations.
>
> So unless there is some way to issue a single request that both
> bzr-svn and the smart server (and some others ?) can *share* to
> learn about the server abilities to talk to them, we are in a
> dead-end.
>   
IIRC we also concluded that it wasn't possible to do this in a single
request and that there was no way to avoid using two roundtrips.
> ISTM that Andrew had an explanation about why the smart server
> couldn't use OPTIONS but I can't remember the details (more
> configuration on the server side maybe ?).
>   
The problem with OPTIONS is that it makes it impossible to e.g. use a
CGI script for the smart server, since that can't manipulate the OPTIONS
returned by the server on a parent directory.

Cheers,

Jelmer