Gregory Szorc <gregory.szorc@gmail.com> [Tue, 10 Apr 2018 13:07:13 -0700] rev 37553
httppeer: allow opener to be passed to makepeer()
This allows us to use makepeer() in `hg debugwireproto`.
Differential Revision: https://phab.mercurial-scm.org/D3238
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 10 Apr 2018 13:11:40 -0700] rev 37552
httppeer: perform capabilities request in makepeer()
Previously, we constructed an httppeer then always ran _fetchcaps()
to issue the capabilities command.
We want to issue the capabilities command before constructing a
peer instance so we can construct an appropriate peer instance
depending on the capabilities result.
With the code for making and sending requests moved out of httppeer,
it is now possible to send command requests without an httppeer.
This commit creates a new function for making the capabilities
request and calls it as part of makepeer().
This code should be functionality equivalent to what existed before.
Differential Revision: https://phab.mercurial-scm.org/D3237
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 10 Apr 2018 12:52:29 -0700] rev 37551
httppeer: extract common response handling into own function
This allows the common redirect detection, content type
validation, and decompression wrapping to be usable outside of
httppeer instances.
Differential Revision: https://phab.mercurial-scm.org/D3236
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 10 Apr 2018 12:12:07 -0700] rev 37550
httppeer: move error handling and response wrapping into sendrequest
This is common for all HTTP requests. It should be part of
sendrequest().
Differential Revision: https://phab.mercurial-scm.org/D3235
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 10 Apr 2018 10:51:12 -0700] rev 37549
httppeer: extract code for creating a request into own function
Some of this feels awkward, such as having to pass in a function
to evaluate a capability. And this code is generally pretty difficult
to read. I didn't want to perform too much refactoring as part of
the code move since it would make review more difficult.
Differential Revision: https://phab.mercurial-scm.org/D3234
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 10 Apr 2018 10:27:49 -0700] rev 37548
httppeer: extract code for performing an HTTP request
This is generic and doesn't need to live as a method of httppeer.
Differential Revision: https://phab.mercurial-scm.org/D3233
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 10 Apr 2018 10:22:26 -0700] rev 37547
httppeer: move requestbuilder defaults into makepeer() argument
Upcoming commits will move the initial ?cmd=capabilities handshake
request out of httppeer so the handshake can be performed before a
peer instance is constructed. In order to do this, we'll need to
refactor code for making HTTP requests.
The type used to construct HTTP requests is configurable. If we'll
be making HTTP requests outside of httppeer, we should be able to
use a custom request builder. So move the definition of that type
into makepeer().
Extensions can monkeypatch the function and override the argument
value.
Differential Revision: https://phab.mercurial-scm.org/D3232
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 09 Apr 2018 19:35:39 -0700] rev 37546
wireproto: move version 2 command handlers to wireprotov2server
This is relatively straightforward.
As part of this, we introduced a local @wireprotocommand that
wraps the main one and defines a v2 only policy by default.
Because the hacky HTTPv2 peer isn't using capabilities response
yet, we had to move some code around to force import of
wireprotov2server so commands are registered. This is super
hacky. But this code will go away once the HTTPv2 peer is using
the capabilities response to derive permissions.
Differential Revision: https://phab.mercurial-scm.org/D3231
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 09 Apr 2018 19:35:04 -0700] rev 37545
wireproto: extract HTTP version 2 code to own module
wireprotoserver has generic and version 1 server code. The wireproto
module also has both version 1 and version 2 command implementations.
Upcoming work I want to do will make it difficult for this code to
live in the current locations. Plus, it kind of makes sense for the
version 2 code to live in an isolated module.
This commit copies the HTTPv2 bits from wireprotoserver into a new
module. We do it as a file copy to preserve history. A future
commit will be copying wire protocol commands into this module
as well. But there is little history of that code, so it makes
sense to take history for wireprotoserver.
Differential Revision: https://phab.mercurial-scm.org/D3230
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 09 Apr 2018 16:54:20 -0700] rev 37544
wireproto: client reactor support for receiving frames
We can now feed received frames into the client reactor and it will
validate their sanity, dispatch them appropriately.
The hacky HTTP peer has been updated to use the new code. No
existing tests changed, somewhat proving the code works as
expected.
Rudimentary unit tests for the new functionality have been
implemented.
Differential Revision: https://phab.mercurial-scm.org/D3224