wireproto: define and implement HTTP handshake to upgrade protocol
When clients connect to repositories over HTTP, they issue a request
to the well-known URL "?cmd=capabilities" to fetch the repository
capabilities. This is the handshake portion of the HTTP protocol.
This commit defines a mechanism to use that HTTP request to return
information about modern server features.
If a client sends an X-HgUpgrade-* header containing a list of
client-supported API names, the server responds with a response
containing information about available services. This includes
the normal capabilities string. So if the server doesn't support
any newer services, the client can easily fall back.
By advertising supported services from clients, server operators
can see and log what client support exists in the wild. This will
also help with debugging.
The response contains the base path to API services. We know there
are potential issues with the <repo>/api/ URL space conflicting with
hgwebdir and subrepos. By making the API URL dynamic from the
perspective of the client, the URL for APIs is not subject to backwards
compatibility concerns - at least as long as a ?cmd=capabilities request
is made.
We've also defined the ``cbor`` client capability for the X-HgProto-*
header. This MUST be sent in order to get the modern response from
"?cmd=capabilities". During implementation, I initially always sent
an application/mercurial-cbor response. However, the handshake
mechanism will be more future compatible if the client is in charge
of which formats to request. We already perform content negotiation
from X-HgProto-*, so keying off this for the capabilities response
feels appropriate.
In addition, I initially used application/cbor. However, it is
conceivable that a non-Mercurial server could serve application/cbor.
To rule out this possibility, I've invented a new media type that
is Mercurial specific and can't be confused for generic CBOR.
Differential Revision: https://phab.mercurial-scm.org/D3242
============================================
Testing obsolescence markers push: Cases D.2
============================================
Mercurial pushes obsolescences markers relevant to the "pushed-set", the set of
all changesets that requested to be "in sync" after the push (even if they are
already on both side).
This test belongs to a series of tests checking such set is properly computed
and applied. This does not tests "obsmarkers" discovery capabilities.
Category D: Partial Information Case
TestCase 2: missing prune target (prune in "pushed set")
D.2 missing prune target (prune in "pushed set")
================================================
.. {{{
.. A ø⇠✕ A'
.. |/
.. ● O
.. }}}
..
.. Marker exist from:
..
.. * A' succeed to A
.. * A' (prune)
..
.. Command runs:
..
.. * hg push
..
.. Expected exchange:
..
.. * `A ø⇠o A'`
.. * A' (prune)
Setup
-----
$ . $TESTDIR/testlib/exchange-obsmarker-util.sh
Initial
$ setuprepos D.2
creating test repo for test case D.2
- pulldest
- main
- pushdest
cd into `main` and proceed with env setup
$ cd main
$ mkcommit A0
$ hg up -q 0
$ mkcommit A1
created new head
$ hg debugobsolete `getid 'desc(A0)'` `getid 'desc(A1)'`
obsoleted 1 changesets
$ hg prune --date '0 0' .
obsoleted 1 changesets
$ hg strip --hidden -q 'desc(A1)'
$ hg log -G --hidden
x 28b51eb45704 (draft): A0
|
@ a9bdc8b26820 (public): O
$ inspect_obsmarkers
obsstore content
================
28b51eb45704506b5c603decd6bf7ac5e0f6a52f e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 (Thu Jan 01 00:00:00 1970 +0000) {'user': 'test'}
e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 {a9bdc8b26820b1b87d585b82eb0ceb4a2ecdbc04} (Thu Jan 01 00:00:00 1970 +0000) {'user': 'test'}
$ cd ..
$ cd ..
Actual Test
-----------
$ dotest D.2
## Running testcase D.2
## initial state
# obstore: main
28b51eb45704506b5c603decd6bf7ac5e0f6a52f e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 (Thu Jan 01 00:00:00 1970 +0000) {'user': 'test'}
e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 {a9bdc8b26820b1b87d585b82eb0ceb4a2ecdbc04} (Thu Jan 01 00:00:00 1970 +0000) {'user': 'test'}
# obstore: pushdest
# obstore: pulldest
## pushing from main to pushdest
pushing to pushdest
searching for changes
no changes found
remote: 2 new obsolescence markers
## post push state
# obstore: main
28b51eb45704506b5c603decd6bf7ac5e0f6a52f e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 (Thu Jan 01 00:00:00 1970 +0000) {'user': 'test'}
e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 {a9bdc8b26820b1b87d585b82eb0ceb4a2ecdbc04} (Thu Jan 01 00:00:00 1970 +0000) {'user': 'test'}
# obstore: pushdest
28b51eb45704506b5c603decd6bf7ac5e0f6a52f e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 (Thu Jan 01 00:00:00 1970 +0000) {'user': 'test'}
e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 {a9bdc8b26820b1b87d585b82eb0ceb4a2ecdbc04} (Thu Jan 01 00:00:00 1970 +0000) {'user': 'test'}
# obstore: pulldest
## pulling from main into pulldest
pulling from main
searching for changes
no changes found
2 new obsolescence markers
## post pull state
# obstore: main
28b51eb45704506b5c603decd6bf7ac5e0f6a52f e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 (Thu Jan 01 00:00:00 1970 +0000) {'user': 'test'}
e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 {a9bdc8b26820b1b87d585b82eb0ceb4a2ecdbc04} (Thu Jan 01 00:00:00 1970 +0000) {'user': 'test'}
# obstore: pushdest
28b51eb45704506b5c603decd6bf7ac5e0f6a52f e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 (Thu Jan 01 00:00:00 1970 +0000) {'user': 'test'}
e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 {a9bdc8b26820b1b87d585b82eb0ceb4a2ecdbc04} (Thu Jan 01 00:00:00 1970 +0000) {'user': 'test'}
# obstore: pulldest
28b51eb45704506b5c603decd6bf7ac5e0f6a52f e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 (Thu Jan 01 00:00:00 1970 +0000) {'user': 'test'}
e5ea8f9c73143125d36658e90ef70c6d2027a5b7 0 {a9bdc8b26820b1b87d585b82eb0ceb4a2ecdbc04} (Thu Jan 01 00:00:00 1970 +0000) {'user': 'test'}