wireproto: service multiple command requests per HTTP request

Now that our new frame-based protocol server can understand how
to ingest multiple, possibly interleaved, command requests, let's
hook it up to the HTTP server.

The code on the HTTP side of things is still a bit hacky. We need
a bit of work around error handling, content types, etc. But it's
a start.

Among the added tests, we demonstrate that a client can send frames
for multiple commands iterleaved with each other and that a later
issued command can respond before the first one has finished
sending. This makes our multi-request model technically superior
to the previous "batch" command.

Differential Revision: https://phab.mercurial-scm.org/D2871

mercurial/help/internals/wireprotocol.txt

@@ -1,1390 +1,1412 b''
 The Mercurial wire protocol is a request-response based protocol
 with multiple wire representations.
 
 Each request is modeled as a command name, a dictionary of arguments, and
 optional raw input. Command arguments and their types are intrinsic
 properties of commands. So is the response type of the command. This means
 clients can't always send arbitrary arguments to servers and servers can't
 return multiple response types.
 
 The protocol is synchronous and does not support multiplexing (concurrent
 commands).
 
 Handshake
 =========
 
 It is required or common for clients to perform a *handshake* when connecting
 to a server. The handshake serves the following purposes:
 
 * Negotiating protocol/transport level options
 * Allows the client to learn about server capabilities to influence
   future requests
 * Ensures the underlying transport channel is in a *clean* state
 
 An important goal of the handshake is to allow clients to use more modern
 wire protocol features. By default, clients must assume they are talking
 to an old version of Mercurial server (possibly even the very first
 implementation). So, clients should not attempt to call or utilize modern
 wire protocol features until they have confirmation that the server
 supports them. The handshake implementation is designed to allow both
 ends to utilize the latest set of features and capabilities with as
 few round trips as possible.
 
 The handshake mechanism varies by transport and protocol and is documented
 in the sections below.
 
 HTTP Protocol
 =============
 
 Handshake
 ---------
 
 The client sends a ``capabilities`` command request (``?cmd=capabilities``)
 as soon as HTTP requests may be issued.
 
 The server responds with a capabilities string, which the client parses to
 learn about the server's abilities.
 
 HTTP Version 1 Transport
 ------------------------
 
 Commands are issued as HTTP/1.0 or HTTP/1.1 requests. Commands are
 sent to the base URL of the repository with the command name sent in
 the ``cmd`` query string parameter. e.g.
 ``https://example.com/repo?cmd=capabilities``. The HTTP method is ``GET``
 or ``POST`` depending on the command and whether there is a request
 body.
 
 Command arguments can be sent multiple ways.
 
 The simplest is part of the URL query string using ``x-www-form-urlencoded``
 encoding (see Python's ``urllib.urlencode()``. However, many servers impose
 length limitations on the URL. So this mechanism is typically only used if
 the server doesn't support other mechanisms.
 
 If the server supports the ``httpheader`` capability, command arguments can
 be sent in HTTP request headers named ``X-HgArg-<N>`` where ``<N>`` is an
 integer starting at 1. A ``x-www-form-urlencoded`` representation of the
 arguments is obtained. This full string is then split into chunks and sent
 in numbered ``X-HgArg-<N>`` headers. The maximum length of each HTTP header
 is defined by the server in the ``httpheader`` capability value, which defaults
 to ``1024``. The server reassembles the encoded arguments string by
 concatenating the ``X-HgArg-<N>`` headers then URL decodes them into a
 dictionary.
 
 The list of ``X-HgArg-<N>`` headers should be added to the ``Vary`` request
 header to instruct caches to take these headers into consideration when caching
 requests.
 
 If the server supports the ``httppostargs`` capability, the client
 may send command arguments in the HTTP request body as part of an
 HTTP POST request. The command arguments will be URL encoded just like
 they would for sending them via HTTP headers. However, no splitting is
 performed: the raw arguments are included in the HTTP request body.
 
 The client sends a ``X-HgArgs-Post`` header with the string length of the
 encoded arguments data. Additional data may be included in the HTTP
 request body immediately following the argument data. The offset of the
 non-argument data is defined by the ``X-HgArgs-Post`` header. The
 ``X-HgArgs-Post`` header is not required if there is no argument data.
 
 Additional command data can be sent as part of the HTTP request body. The
 default ``Content-Type`` when sending data is ``application/mercurial-0.1``.
 A ``Content-Length`` header is currently always sent.
 
 Example HTTP requests::
 
     GET /repo?cmd=capabilities
     X-HgArg-1: foo=bar&baz=hello%20world
 
 The request media type should be chosen based on server support. If the
 ``httpmediatype`` server capability is present, the client should send
 the newest mutually supported media type. If this capability is absent,
 the client must assume the server only supports the
 ``application/mercurial-0.1`` media type.
 
 The ``Content-Type`` HTTP response header identifies the response as coming
 from Mercurial and can also be used to signal an error has occurred.
 
 The ``application/mercurial-*`` media types indicate a generic Mercurial
 data type.
 
 The ``application/mercurial-0.1`` media type is raw Mercurial data. It is the
 predecessor of the format below.
 
 The ``application/mercurial-0.2`` media type is compression framed Mercurial
 data. The first byte of the payload indicates the length of the compression
 format identifier that follows. Next are N bytes indicating the compression
 format. e.g. ``zlib``. The remaining bytes are compressed according to that
 compression format. The decompressed data behaves the same as with
 ``application/mercurial-0.1``.
 
 The ``application/hg-error`` media type indicates a generic error occurred.
 The content of the HTTP response body typically holds text describing the
 error.
 
 The ``application/hg-changegroup`` media type indicates a changegroup response
 type.
 
 Clients also accept the ``text/plain`` media type. All other media
 types should cause the client to error.
 
 Behavior of media types is further described in the ``Content Negotiation``
 section below.
 
 Clients should issue a ``User-Agent`` request header that identifies the client.
 The server should not use the ``User-Agent`` for feature detection.
 
 A command returning a ``string`` response issues a
 ``application/mercurial-0.*`` media type and the HTTP response body contains
 the raw string value (after compression decoding, if used). A
 ``Content-Length`` header is typically issued, but not required.
 
 A command returning a ``stream`` response issues a
 ``application/mercurial-0.*`` media type and the HTTP response is typically
 using *chunked transfer* (``Transfer-Encoding: chunked``).
 
 HTTP Version 2 Transport
 ------------------------
 
 **Experimental - feature under active development**
 
 Version 2 of the HTTP protocol is exposed under the ``/api/*`` URL space.
 It's final API name is not yet formalized.
 
 Commands are triggered by sending HTTP POST requests against URLs of the
 form ``<permission>/<command>``, where ``<permission>`` is ``ro`` or
 ``rw``, meaning read-only and read-write, respectively and ``<command>``
 is a named wire protocol command.
 
 Non-POST request methods MUST be rejected by the server with an HTTP
 405 response.
 
 Commands that modify repository state in meaningful ways MUST NOT be
 exposed under the ``ro`` URL prefix. All available commands MUST be
 available under the ``rw`` URL prefix.
 
 Server adminstrators MAY implement blanket HTTP authentication keyed
 off the URL prefix. For example, a server may require authentication
 for all ``rw/*`` URLs and let unauthenticated requests to ``ro/*``
 URL proceed. A server MAY issue an HTTP 401, 403, or 407 response
 in accordance with RFC 7235. Clients SHOULD recognize the HTTP Basic
 (RFC 7617) and Digest (RFC 7616) authentication schemes. Clients SHOULD
 make an attempt to recognize unknown schemes using the
 ``WWW-Authenticate`` response header on a 401 response, as defined by
 RFC 7235.
 
 Read-only commands are accessible under ``rw/*`` URLs so clients can
 signal the intent of the operation very early in the connection
 lifecycle. For example, a ``push`` operation - which consists of
 various read-only commands mixed with at least one read-write command -
 can perform all commands against ``rw/*`` URLs so that any server-side
 authentication requirements are discovered upon attempting the first
 command - not potentially several commands into the exchange. This
 allows clients to fail faster or prompt for credentials as soon as the
 exchange takes place. This provides a better end-user experience.
 
 Requests to unknown commands or URLS result in an HTTP 404.
 TODO formally define response type, how error is communicated, etc.
 
 HTTP request and response bodies use the *Unified Frame-Based Protocol*
 (defined below) for media exchange. The entirety of the HTTP message
 body is 0 or more frames as defined by this protocol.
 
 Clients and servers MUST advertise the ``TBD`` media type via the
 ``Content-Type`` request and response headers. In addition, clients MUST
 advertise this media type value in their ``Accept`` request header in all
 requests.
 TODO finalize the media type. For now, it is defined in wireprotoserver.py.
 
 Servers receiving requests without an ``Accept`` header SHOULD respond with
 an HTTP 406.
 
 Servers receiving requests with an invalid ``Content-Type`` header SHOULD
 respond with an HTTP 415.
 
+The command to run is specified in the POST payload as defined by the
+*Unified Frame-Based Protocol*. This is redundant with data already
+encoded in the URL. This is by design, so server operators can have
+better understanding about server activity from looking merely at
+HTTP access logs.
+
+In most circumstances, the command specified in the URL MUST match
+the command specified in the frame-based payload or the server will
+respond with an error. The exception to this is the special
+``multirequest`` URL. (See below.) In addition, HTTP requests
+are limited to one command invocation. The exception is the special
+``multirequest`` URL.
+
+The ``multirequest`` command endpoints (``ro/multirequest`` and
+``rw/multirequest``) are special in that they allow the execution of
+*any* command and allow the execution of multiple commands. If the
+HTTP request issues multiple commands across multiple frames, all
+issued commands will be processed by the server. Per the defined
+behavior of the *Unified Frame-Based Protocol*, commands may be
+issued interleaved and responses may come back in a different order
+than they were issued. Clients MUST be able to deal with this.
+
 SSH Protocol
 ============
 
 Handshake
 ---------
 
 For all clients, the handshake consists of the client sending 1 or more
 commands to the server using version 1 of the transport. Servers respond
 to commands they know how to respond to and send an empty response (``0\n``)
 for unknown commands (per standard behavior of version 1 of the transport).
 Clients then typically look for a response to the newest sent command to
 determine which transport version to use and what the available features for
 the connection and server are.
 
 Preceding any response from client-issued commands, the server may print
 non-protocol output. It is common for SSH servers to print banners, message
 of the day announcements, etc when clients connect. It is assumed that any
 such *banner* output will precede any Mercurial server output. So clients
 must be prepared to handle server output on initial connect that isn't
 in response to any client-issued command and doesn't conform to Mercurial's
 wire protocol. This *banner* output should only be on stdout. However,
 some servers may send output on stderr.
 
 Pre 0.9.1 clients issue a ``between`` command with the ``pairs`` argument
 having the value
 ``0000000000000000000000000000000000000000-0000000000000000000000000000000000000000``.
 
 The ``between`` command has been supported since the original Mercurial
 SSH server. Requesting the empty range will return a ``\n`` string response,
 which will be encoded as ``1\n\n`` (value length of ``1`` followed by a newline
 followed by the value, which happens to be a newline).
 
 For pre 0.9.1 clients and all servers, the exchange looks like::
 
    c: between\n
    c: pairs 81\n
    c: 0000000000000000000000000000000000000000-0000000000000000000000000000000000000000
    s: 1\n
    s: \n
 
 0.9.1+ clients send a ``hello`` command (with no arguments) before the
 ``between`` command. The response to this command allows clients to
 discover server capabilities and settings.
 
 An example exchange between 0.9.1+ clients and a ``hello`` aware server looks
 like::
 
    c: hello\n
    c: between\n
    c: pairs 81\n
    c: 0000000000000000000000000000000000000000-0000000000000000000000000000000000000000
    s: 324\n
    s: capabilities: lookup changegroupsubset branchmap pushkey known getbundle ...\n
    s: 1\n
    s: \n
 
 And a similar scenario but with servers sending a banner on connect::
 
    c: hello\n
    c: between\n
    c: pairs 81\n
    c: 0000000000000000000000000000000000000000-0000000000000000000000000000000000000000
    s: welcome to the server\n
    s: if you find any issues, email [e-mail]\n
    s: 324\n
    s: capabilities: lookup changegroupsubset branchmap pushkey known getbundle ...\n
    s: 1\n
    s: \n
 
 Note that output from the ``hello`` command is terminated by a ``\n``. This is
 part of the response payload and not part of the wire protocol adding a newline
 after responses. In other words, the length of the response contains the
 trailing ``\n``.
 
 Clients supporting version 2 of the SSH transport send a line beginning
 with ``upgrade`` before the ``hello`` and ``between`` commands. The line
 (which isn't a well-formed command line because it doesn't consist of a
 single command name) serves to both communicate the client's intent to
 switch to transport version 2 (transports are version 1 by default) as
 well as to advertise the client's transport-level capabilities so the
 server may satisfy that request immediately.
 
 The upgrade line has the form:
 
     upgrade <token> <transport capabilities>
 
 That is the literal string ``upgrade`` followed by a space, followed by
 a randomly generated string, followed by a space, followed by a string
 denoting the client's transport capabilities.
 
 The token can be anything. However, a random UUID is recommended. (Use
 of version 4 UUIDs is recommended because version 1 UUIDs can leak the
 client's MAC address.)
 
 The transport capabilities string is a URL/percent encoded string
 containing key-value pairs defining the client's transport-level
 capabilities. The following capabilities are defined:
 
 proto
    A comma-delimited list of transport protocol versions the client
    supports. e.g. ``ssh-v2``.
 
 If the server does not recognize the ``upgrade`` line, it should issue
 an empty response and continue processing the ``hello`` and ``between``
 commands. Here is an example handshake between a version 2 aware client
 and a non version 2 aware server:
 
    c: upgrade 2e82ab3f-9ce3-4b4e-8f8c-6fd1c0e9e23a proto=ssh-v2
    c: hello\n
    c: between\n
    c: pairs 81\n
    c: 0000000000000000000000000000000000000000-0000000000000000000000000000000000000000
    s: 0\n
    s: 324\n
    s: capabilities: lookup changegroupsubset branchmap pushkey known getbundle ...\n
    s: 1\n
    s: \n
 
 (The initial ``0\n`` line from the server indicates an empty response to
 the unknown ``upgrade ..`` command/line.)
 
 If the server recognizes the ``upgrade`` line and is willing to satisfy that
 upgrade request, it replies to with a payload of the following form:
 
    upgraded <token> <transport name>\n
 
 This line is the literal string ``upgraded``, a space, the token that was
 specified by the client in its ``upgrade ...`` request line, a space, and the
 name of the transport protocol that was chosen by the server. The transport
 name MUST match one of the names the client specified in the ``proto`` field
 of its ``upgrade ...`` request line.
 
 If a server issues an ``upgraded`` response, it MUST also read and ignore
 the lines associated with the ``hello`` and ``between`` command requests
 that were issued by the server. It is assumed that the negotiated transport
 will respond with equivalent requested information following the transport
 handshake.
 
 All data following the ``\n`` terminating the ``upgraded`` line is the
 domain of the negotiated transport. It is common for the data immediately
 following to contain additional metadata about the state of the transport and
 the server. However, this isn't strictly speaking part of the transport
 handshake and isn't covered by this section.
 
 Here is an example handshake between a version 2 aware client and a version
 2 aware server:
 
    c:  upgrade 2e82ab3f-9ce3-4b4e-8f8c-6fd1c0e9e23a proto=ssh-v2
    c:  hello\n
    c:  between\n
    c:  pairs 81\n
    c:  0000000000000000000000000000000000000000-0000000000000000000000000000000000000000
    s: upgraded 2e82ab3f-9ce3-4b4e-8f8c-6fd1c0e9e23a ssh-v2\n
    s: <additional transport specific data>
 
 The client-issued token that is echoed in the response provides a more
 resilient mechanism for differentiating *banner* output from Mercurial
 output. In version 1, properly formatted banner output could get confused
 for Mercurial server output. By submitting a randomly generated token
 that is then present in the response, the client can look for that token
 in response lines and have reasonable certainty that the line did not
 originate from a *banner* message.
 
 SSH Version 1 Transport
 -----------------------
 
 The SSH transport (version 1) is a custom text-based protocol suitable for
 use over any bi-directional stream transport. It is most commonly used with
 SSH.
 
 A SSH transport server can be started with ``hg serve --stdio``. The stdin,
 stderr, and stdout file descriptors of the started process are used to exchange
 data. When Mercurial connects to a remote server over SSH, it actually starts
 a ``hg serve --stdio`` process on the remote server.
 
 Commands are issued by sending the command name followed by a trailing newline
 ``\n`` to the server. e.g. ``capabilities\n``.
 
 Command arguments are sent in the following format::
 
     <argument> <length>\n<value>
 
 That is, the argument string name followed by a space followed by the
 integer length of the value (expressed as a string) followed by a newline
 (``\n``) followed by the raw argument value.
 
 Dictionary arguments are encoded differently::
 
     <argument> <# elements>\n
     <key1> <length1>\n<value1>
     <key2> <length2>\n<value2>
     ...
 
 Non-argument data is sent immediately after the final argument value. It is
 encoded in chunks::
 
     <length>\n<data>
 
 Each command declares a list of supported arguments and their types. If a
 client sends an unknown argument to the server, the server should abort
 immediately. The special argument ``*`` in a command's definition indicates
 that all argument names are allowed.
 
 The definition of supported arguments and types is initially made when a
 new command is implemented. The client and server must initially independently
 agree on the arguments and their types. This initial set of arguments can be
 supplemented through the presence of *capabilities* advertised by the server.
 
 Each command has a defined expected response type.
 
 A ``string`` response type is a length framed value. The response consists of
 the string encoded integer length of a value followed by a newline (``\n``)
 followed by the value. Empty values are allowed (and are represented as
 ``0\n``).
 
 A ``stream`` response type consists of raw bytes of data. There is no framing.
 
 A generic error response type is also supported. It consists of a an error
 message written to ``stderr`` followed by ``\n-\n``. In addition, ``\n`` is
 written to ``stdout``.
 
 If the server receives an unknown command, it will send an empty ``string``
 response.
 
 The server terminates if it receives an empty command (a ``\n`` character).
 
 SSH Version 2 Transport
 -----------------------
 
 **Experimental and under development**
 
 Version 2 of the SSH transport behaves identically to version 1 of the SSH
 transport with the exception of handshake semantics. See above for how
 version 2 of the SSH transport is negotiated.
 
 Immediately following the ``upgraded`` line signaling a switch to version
 2 of the SSH protocol, the server automatically sends additional details
 about the capabilities of the remote server. This has the form:
 
    <integer length of value>\n
    capabilities: ...\n
 
 e.g.
 
    s: upgraded 2e82ab3f-9ce3-4b4e-8f8c-6fd1c0e9e23a ssh-v2\n
    s: 240\n
    s: capabilities: known getbundle batch ...\n
 
 Following capabilities advertisement, the peers communicate using version
 1 of the SSH transport.
 
 Unified Frame-Based Protocol
 ============================
 
 **Experimental and under development**
 
 The *Unified Frame-Based Protocol* is a communications protocol between
 Mercurial peers. The protocol aims to be mostly transport agnostic
 (works similarly on HTTP, SSH, etc).
 
 To operate the protocol, a bi-directional, half-duplex pipe supporting
 ordered sends and receives is required. That is, each peer has one pipe
 for sending data and another for receiving.
 
 The protocol is request-response based: the client issues requests to
 the server, which issues replies to those requests. Server-initiated
 messaging is not currently supported, but this specification carves
 out room to implement it.
 
 All data is read and written in atomic units called *frames*. These
 are conceptually similar to TCP packets. Higher-level functionality
 is built on the exchange and processing of frames.
 
 All frames are associated with a numbered request. Frames can thus
 be logically grouped by their request ID.
 
 Frames begin with a 6 octet header followed by a variable length
 payload::
 
     +-----------------------------------------------+
     |                 Length (24)                   |
     +---------------------------------+-------------+
     |         Request ID (16)         |
     +----------+-----------+----------+
     | Type (4) | Flags (4) |
     +==========+===========+========================================|
     |                     Frame Payload (0...)                    ...
     +---------------------------------------------------------------+
 
 The length of the frame payload is expressed as an unsigned 24 bit
 little endian integer. Values larger than 65535 MUST NOT be used unless
 given permission by the server as part of the negotiated capabilities
 during the handshake. The frame header is not part of the advertised
 frame length.
 
 The 16-bit ``Request ID`` field denotes the integer request identifier,
 stored as an unsigned little endian integer. Odd numbered requests are
 client-initiated. Even numbered requests are server-initiated. This
 refers to where the *request* was initiated - not where the *frame* was
 initiated, so servers will send frames with odd ``Request ID`` in
 response to client-initiated requests. Implementations are advised to
 start ordering request identifiers at ``1`` and ``0``, increment by
 ``2``, and wrap around if all available numbers have been exhausted.
 
 The 4-bit ``Type`` field denotes the type of message being sent.
 
 The 4-bit ``Flags`` field defines special, per-type attributes for
 the frame.
 
 The sections below define the frame types and their behavior.
 
 Command Request (``0x01``)
 --------------------------
 
 This frame contains a request to run a command.
 
 The name of the command to run constitutes the entirety of the frame
 payload.
 
 This frame type MUST ONLY be sent from clients to servers: it is illegal
 for a server to send this frame to a client.
 
 The following flag values are defined for this type:
 
 0x01
    End of command data. When set, the client will not send any command
    arguments or additional command data. When set, the command has been
    fully issued and the server has the full context to process the command.
    The next frame issued by the client is not part of this command.
 0x02
    Command argument frames expected. When set, the client will send
    *Command Argument* frames containing command argument data.
 0x04
    Command data frames expected. When set, the client will send
    *Command Data* frames containing a raw stream of data for this
    command.
 
 The ``0x01`` flag is mutually exclusive with both the ``0x02`` and ``0x04``
 flags.
 
 Command Argument (``0x02``)
 ---------------------------
 
 This frame contains a named argument for a command.
 
 The frame type MUST ONLY be sent from clients to servers: it is illegal
 for a server to send this frame to a client.
 
 The payload consists of:
 
 * A 16-bit little endian integer denoting the length of the
   argument name.
 * A 16-bit little endian integer denoting the length of the
   argument value.
 * N bytes of ASCII data containing the argument name.
 * N bytes of binary data containing the argument value.
 
 The payload MUST hold the entirety of the 32-bit header and the
 argument name. The argument value MAY span multiple frames. If this
 occurs, the appropriate frame flag should be set to indicate this.
 
 The following flag values are defined for this type:
 
 0x01
    Argument data continuation. When set, the data for this argument did
    not fit in a single frame and the next frame will contain additional
    argument data.
 
 0x02
    End of arguments data. When set, the client will not send any more
    command arguments for the command this frame is associated with.
    The next frame issued by the client will be command data or
    belong to a separate request.
 
 Command Data (``0x03``)
 -----------------------
 
 This frame contains raw data for a command.
 
 Most commands can be executed by specifying arguments. However,
 arguments have an upper bound to their length. For commands that
 accept data that is beyond this length or whose length isn't known
 when the command is initially sent, they will need to stream
 arbitrary data to the server. This frame type facilitates the sending
 of this data.
 
 The payload of this frame type consists of a stream of raw data to be
 consumed by the command handler on the server. The format of the data
 is command specific.
 
 The following flag values are defined for this type:
 
 0x01
    Command data continuation. When set, the data for this command
    continues into a subsequent frame.
 
 0x02
    End of data. When set, command data has been fully sent to the
    server. The command has been fully issued and no new data for this
    command will be sent. The next frame will belong to a new command.
 
 Bytes Response Data (``0x04``)
 ------------------------------
 
 This frame contains raw bytes response data to an issued command.
 
 The following flag values are defined for this type:
 
 0x01
    Data continuation. When set, an additional frame containing raw
    response data will follow.
 0x02
    End of data. When sent, the response data has been fully sent and
    no additional frames for this response will be sent.
 
 The ``0x01`` flag is mutually exclusive with the ``0x02`` flag.
 
 Error Response (``0x05``)
 -------------------------
 
 An error occurred when processing a request. This could indicate
 a protocol-level failure or an application level failure depending
 on the flags for this message type.
 
 The payload for this type is an error message that should be
 displayed to the user.
 
 The following flag values are defined for this type:
 
 0x01
    The error occurred at the transport/protocol level. If set, the
    connection should be closed.
 0x02
    The error occurred at the application level. e.g. invalid command.
 
 Issuing Commands
 ----------------
 
 A client can request that a remote run a command by sending it
 frames defining that command. This logical stream is composed of
 1 ``Command Request`` frame, 0 or more ``Command Argument`` frames,
 and 0 or more ``Command Data`` frames.
 
 All frames composing a single command request MUST be associated with
 the same ``Request ID``.
 
 Clients MAY send additional command requests without waiting on the
 response to a previous command request. If they do so, they MUST ensure
 that the ``Request ID`` field of outbound frames does not conflict
 with that of an active ``Request ID`` whose response has not yet been
 fully received.
 
 Servers MAY respond to commands in a different order than they were
 sent over the wire. Clients MUST be prepared to deal with this. Servers
 also MAY start executing commands in a different order than they were
 received, or MAY execute multiple commands concurrently.
 
 If there is a dependency between commands or a race condition between
 commands executing (e.g. a read-only command that depends on the results
 of a command that mutates the repository), then clients MUST NOT send
 frames issuing a command until a response to all dependent commands has
 been received.
 TODO think about whether we should express dependencies between commands
 to avoid roundtrip latency.
 
 Argument frames are the recommended mechanism for transferring fixed
 sets of parameters to a command. Data frames are appropriate for
 transferring variable data. A similar comparison would be to HTTP:
 argument frames are headers and the message body is data frames.
 
 It is recommended for servers to delay the dispatch of a command
 until all argument frames for that command have been received. Servers
 MAY impose limits on the maximum argument size.
 TODO define failure mechanism.
 
 Servers MAY dispatch to commands immediately once argument data
 is available or delay until command data is received in full.
 
 Capabilities
 ============
 
 Servers advertise supported wire protocol features. This allows clients to
 probe for server features before blindly calling a command or passing a
 specific argument.
 
 The server's features are exposed via a *capabilities* string. This is a
 space-delimited string of tokens/features. Some features are single words
 like ``lookup`` or ``batch``. Others are complicated key-value pairs
 advertising sub-features. e.g. ``httpheader=2048``. When complex, non-word
 values are used, each feature name can define its own encoding of sub-values.
 Comma-delimited and ``x-www-form-urlencoded`` values are common.
 
 The following document capabilities defined by the canonical Mercurial server
 implementation.
 
 batch
 -----
 
 Whether the server supports the ``batch`` command.
 
 This capability/command was introduced in Mercurial 1.9 (released July 2011).
 
 branchmap
 ---------
 
 Whether the server supports the ``branchmap`` command.
 
 This capability/command was introduced in Mercurial 1.3 (released July 2009).
 
 bundle2-exp
 -----------
 
 Precursor to ``bundle2`` capability that was used before bundle2 was a
 stable feature.
 
 This capability was introduced in Mercurial 3.0 behind an experimental
 flag. This capability should not be observed in the wild.
 
 bundle2
 -------
 
 Indicates whether the server supports the ``bundle2`` data exchange format.
 
 The value of the capability is a URL quoted, newline (``\n``) delimited
 list of keys or key-value pairs.
 
 A key is simply a URL encoded string.
 
 A key-value pair is a URL encoded key separated from a URL encoded value by
 an ``=``. If the value is a list, elements are delimited by a ``,`` after
 URL encoding.
 
 For example, say we have the values::
 
   {'HG20': [], 'changegroup': ['01', '02'], 'digests': ['sha1', 'sha512']}
 
 We would first construct a string::
 
   HG20\nchangegroup=01,02\ndigests=sha1,sha512
 
 We would then URL quote this string::
 
   HG20%0Achangegroup%3D01%2C02%0Adigests%3Dsha1%2Csha512
 
 This capability was introduced in Mercurial 3.4 (released May 2015).
 
 changegroupsubset
 -----------------
 
 Whether the server supports the ``changegroupsubset`` command.
 
 This capability was introduced in Mercurial 0.9.2 (released December
 2006).
 
 This capability was introduced at the same time as the ``lookup``
 capability/command.
 
 compression
 -----------
 
 Declares support for negotiating compression formats.
 
 Presence of this capability indicates the server supports dynamic selection
 of compression formats based on the client request.
 
 Servers advertising this capability are required to support the
 ``application/mercurial-0.2`` media type in response to commands returning
 streams. Servers may support this media type on any command.
 
 The value of the capability is a comma-delimited list of strings declaring
 supported compression formats. The order of the compression formats is in
 server-preferred order, most preferred first.
 
 The identifiers used by the official Mercurial distribution are:
 
 bzip2
    bzip2
 none
    uncompressed / raw data
 zlib
    zlib (no gzip header)
 zstd
    zstd
 
 This capability was introduced in Mercurial 4.1 (released February 2017).
 
 getbundle
 ---------
 
 Whether the server supports the ``getbundle`` command.
 
 This capability was introduced in Mercurial 1.9 (released July 2011).
 
 httpheader
 ----------
 
 Whether the server supports receiving command arguments via HTTP request
 headers.
 
 The value of the capability is an integer describing the max header
 length that clients should send. Clients should ignore any content after a
 comma in the value, as this is reserved for future use.
 
 This capability was introduced in Mercurial 1.9 (released July 2011).
 
 httpmediatype
 -------------
 
 Indicates which HTTP media types (``Content-Type`` header) the server is
 capable of receiving and sending.
 
 The value of the capability is a comma-delimited list of strings identifying
 support for media type and transmission direction. The following strings may
 be present:
 
 0.1rx
    Indicates server support for receiving ``application/mercurial-0.1`` media
    types.
 
 0.1tx
    Indicates server support for sending ``application/mercurial-0.1`` media
    types.
 
 0.2rx
    Indicates server support for receiving ``application/mercurial-0.2`` media
    types.
 
 0.2tx
    Indicates server support for sending ``application/mercurial-0.2`` media
    types.
 
 minrx=X
    Minimum media type version the server is capable of receiving. Value is a
    string like ``0.2``.
 
    This capability can be used by servers to limit connections from legacy
    clients not using the latest supported media type. However, only clients
    with knowledge of this capability will know to consult this value. This
    capability is present so the client may issue a more user-friendly error
    when the server has locked out a legacy client.
 
 mintx=X
    Minimum media type version the server is capable of sending. Value is a
    string like ``0.1``.
 
 Servers advertising support for the ``application/mercurial-0.2`` media type
 should also advertise the ``compression`` capability.
 
 This capability was introduced in Mercurial 4.1 (released February 2017).
 
 httppostargs
 ------------
 
 **Experimental**
 
 Indicates that the server supports and prefers clients send command arguments
 via a HTTP POST request as part of the request body.
 
 This capability was introduced in Mercurial 3.8 (released May 2016).
 
 known
 -----
 
 Whether the server supports the ``known`` command.
 
 This capability/command was introduced in Mercurial 1.9 (released July 2011).
 
 lookup
 ------
 
 Whether the server supports the ``lookup`` command.
 
 This capability was introduced in Mercurial 0.9.2 (released December
 2006).
 
 This capability was introduced at the same time as the ``changegroupsubset``
 capability/command.
 
 pushkey
 -------
 
 Whether the server supports the ``pushkey`` and ``listkeys`` commands.
 
 This capability was introduced in Mercurial 1.6 (released July 2010).
 
 standardbundle
 --------------
 
 **Unsupported**
 
 This capability was introduced during the Mercurial 0.9.2 development cycle in
 2006. It was never present in a release, as it was replaced by the ``unbundle``
 capability. This capability should not be encountered in the wild.
 
 stream-preferred
 ----------------
 
 If present the server prefers that clients clone using the streaming clone
 protocol (``hg clone --stream``) rather than the standard
 changegroup/bundle based protocol.
 
 This capability was introduced in Mercurial 2.2 (released May 2012).
 
 streamreqs
 ----------
 
 Indicates whether the server supports *streaming clones* and the *requirements*
 that clients must support to receive it.
 
 If present, the server supports the ``stream_out`` command, which transmits
 raw revlogs from the repository instead of changegroups. This provides a faster
 cloning mechanism at the expense of more bandwidth used.
 
 The value of this capability is a comma-delimited list of repo format
 *requirements*. These are requirements that impact the reading of data in
 the ``.hg/store`` directory. An example value is
 ``streamreqs=generaldelta,revlogv1`` indicating the server repo requires
 the ``revlogv1`` and ``generaldelta`` requirements.
 
 If the only format requirement is ``revlogv1``, the server may expose the
 ``stream`` capability instead of the ``streamreqs`` capability.
 
 This capability was introduced in Mercurial 1.7 (released November 2010).
 
 stream
 ------
 
 Whether the server supports *streaming clones* from ``revlogv1`` repos.
 
 If present, the server supports the ``stream_out`` command, which transmits
 raw revlogs from the repository instead of changegroups. This provides a faster
 cloning mechanism at the expense of more bandwidth used.
 
 This capability was introduced in Mercurial 0.9.1 (released July 2006).
 
 When initially introduced, the value of the capability was the numeric
 revlog revision. e.g. ``stream=1``. This indicates the changegroup is using
 ``revlogv1``. This simple integer value wasn't powerful enough, so the
 ``streamreqs`` capability was invented to handle cases where the repo
 requirements have more than just ``revlogv1``. Newer servers omit the
 ``=1`` since it was the only value supported and the value of ``1`` can
 be implied by clients.
 
 unbundlehash
 ------------
 
 Whether the ``unbundle`` commands supports receiving a hash of all the
 heads instead of a list.
 
 For more, see the documentation for the ``unbundle`` command.
 
 This capability was introduced in Mercurial 1.9 (released July 2011).
 
 unbundle
 --------
 
 Whether the server supports pushing via the ``unbundle`` command.
 
 This capability/command has been present since Mercurial 0.9.1 (released
 July 2006).
 
 Mercurial 0.9.2 (released December 2006) added values to the capability
 indicating which bundle types the server supports receiving. This value is a
 comma-delimited list. e.g. ``HG10GZ,HG10BZ,HG10UN``. The order of values
 reflects the priority/preference of that type, where the first value is the
 most preferred type.
 
 Content Negotiation
 ===================
 
 The wire protocol has some mechanisms to help peers determine what content
 types and encoding the other side will accept. Historically, these mechanisms
 have been built into commands themselves because most commands only send a
 well-defined response type and only certain commands needed to support
 functionality like compression.
 
 Currently, only the HTTP version 1 transport supports content negotiation
 at the protocol layer.
 
 HTTP requests advertise supported response formats via the ``X-HgProto-<N>``
 request header, where ``<N>`` is an integer starting at 1 allowing the logical
 value to span multiple headers. This value consists of a list of
 space-delimited parameters. Each parameter denotes a feature or capability.
 
 The following parameters are defined:
 
 0.1
    Indicates the client supports receiving ``application/mercurial-0.1``
    responses.
 
 0.2
    Indicates the client supports receiving ``application/mercurial-0.2``
    responses.
 
 comp
    Indicates compression formats the client can decode. Value is a list of
    comma delimited strings identifying compression formats ordered from
    most preferential to least preferential. e.g. ``comp=zstd,zlib,none``.
 
    This parameter does not have an effect if only the ``0.1`` parameter
    is defined, as support for ``application/mercurial-0.2`` or greater is
    required to use arbitrary compression formats.
 
    If this parameter is not advertised, the server interprets this as
    equivalent to ``zlib,none``.
 
 Clients may choose to only send this header if the ``httpmediatype``
 server capability is present, as currently all server-side features
 consulting this header require the client to opt in to new protocol features
 advertised via the ``httpmediatype`` capability.
 
 A server that doesn't receive an ``X-HgProto-<N>`` header should infer a
 value of ``0.1``. This is compatible with legacy clients.
 
 A server receiving a request indicating support for multiple media type
 versions may respond with any of the supported media types. Not all servers
 may support all media types on all commands.
 
 Commands
 ========
 
 This section contains a list of all wire protocol commands implemented by
 the canonical Mercurial server.
 
 batch
 -----
 
 Issue multiple commands while sending a single command request. The purpose
 of this command is to allow a client to issue multiple commands while avoiding
 multiple round trips to the server therefore enabling commands to complete
 quicker.
 
 The command accepts a ``cmds`` argument that contains a list of commands to
 execute.
 
 The value of ``cmds`` is a ``;`` delimited list of strings. Each string has the
 form ``<command> <arguments>``. That is, the command name followed by a space
 followed by an argument string.
 
 The argument string is a ``,`` delimited list of ``<key>=<value>`` values
 corresponding to command arguments. Both the argument name and value are
 escaped using a special substitution map::
 
    : -> :c
    , -> :o
    ; -> :s
    = -> :e
 
 The response type for this command is ``string``. The value contains a
 ``;`` delimited list of responses for each requested command. Each value
 in this list is escaped using the same substitution map used for arguments.
 
 If an error occurs, the generic error response may be sent.
 
 between
 -------
 
 (Legacy command used for discovery in old clients)
 
 Obtain nodes between pairs of nodes.
 
 The ``pairs`` arguments contains a space-delimited list of ``-`` delimited
 hex node pairs. e.g.::
 
    a072279d3f7fd3a4aa7ffa1a5af8efc573e1c896-6dc58916e7c070f678682bfe404d2e2d68291a18
 
 Return type is a ``string``. Value consists of lines corresponding to each
 requested range. Each line contains a space-delimited list of hex nodes.
 A newline ``\n`` terminates each line, including the last one.
 
 branchmap
 ---------
 
 Obtain heads in named branches.
 
 Accepts no arguments. Return type is a ``string``.
 
 Return value contains lines with URL encoded branch names followed by a space
 followed by a space-delimited list of hex nodes of heads on that branch.
 e.g.::
 
     default a072279d3f7fd3a4aa7ffa1a5af8efc573e1c896 6dc58916e7c070f678682bfe404d2e2d68291a18
     stable baae3bf31522f41dd5e6d7377d0edd8d1cf3fccc
 
 There is no trailing newline.
 
 branches
 --------
 
 (Legacy command used for discovery in old clients. Clients with ``getbundle``
 use the ``known`` and ``heads`` commands instead.)
 
 Obtain ancestor changesets of specific nodes back to a branch point.
 
 Despite the name, this command has nothing to do with Mercurial named branches.
 Instead, it is related to DAG branches.
 
 The command accepts a ``nodes`` argument, which is a string of space-delimited
 hex nodes.
 
 For each node requested, the server will find the first ancestor node that is
 a DAG root or is a merge.
 
 Return type is a ``string``. Return value contains lines with result data for
 each requested node. Each line contains space-delimited nodes followed by a
 newline (``\n``). The 4 nodes reported on each line correspond to the requested
 node, the ancestor node found, and its 2 parent nodes (which may be the null
 node).
 
 capabilities
 ------------
 
 Obtain the capabilities string for the repo.
 
 Unlike the ``hello`` command, the capabilities string is not prefixed.
 There is no trailing newline.
 
 This command does not accept any arguments. Return type is a ``string``.
 
 This command was introduced in Mercurial 0.9.1 (released July 2006).
 
 changegroup
 -----------
 
 (Legacy command: use ``getbundle`` instead)
 
 Obtain a changegroup version 1 with data for changesets that are
 descendants of client-specified changesets.
 
 The ``roots`` arguments contains a list of space-delimited hex nodes.
 
 The server responds with a changegroup version 1 containing all
 changesets between the requested root/base nodes and the repo's head nodes
 at the time of the request.
 
 The return type is a ``stream``.
 
 changegroupsubset
 -----------------
 
 (Legacy command: use ``getbundle`` instead)
 
 Obtain a changegroup version 1 with data for changesetsets between
 client specified base and head nodes.
 
 The ``bases`` argument contains a list of space-delimited hex nodes.
 The ``heads`` argument contains a list of space-delimited hex nodes.
 
 The server responds with a changegroup version 1 containing all
 changesets between the requested base and head nodes at the time of the
 request.
 
 The return type is a ``stream``.
 
 clonebundles
 ------------
 
 Obtains a manifest of bundle URLs available to seed clones.
 
 Each returned line contains a URL followed by metadata. See the
 documentation in the ``clonebundles`` extension for more.
 
 The return type is a ``string``.
 
 getbundle
 ---------
 
 Obtain a bundle containing repository data.
 
 This command accepts the following arguments:
 
 heads
    List of space-delimited hex nodes of heads to retrieve.
 common
    List of space-delimited hex nodes that the client has in common with the
    server.
 obsmarkers
    Boolean indicating whether to include obsolescence markers as part
    of the response. Only works with bundle2.
 bundlecaps
    Comma-delimited set of strings defining client bundle capabilities.
 listkeys
    Comma-delimited list of strings of ``pushkey`` namespaces. For each
    namespace listed, a bundle2 part will be included with the content of
    that namespace.
 cg
    Boolean indicating whether changegroup data is requested.
 cbattempted
    Boolean indicating whether the client attempted to use the *clone bundles*
    feature before performing this request.
 bookmarks
    Boolean indicating whether bookmark data is requested.
 phases
    Boolean indicating whether phases data is requested.
 
 The return type on success is a ``stream`` where the value is bundle.
 On the HTTP version 1 transport, the response is zlib compressed.
 
 If an error occurs, a generic error response can be sent.
 
 Unless the client sends a false value for the ``cg`` argument, the returned
 bundle contains a changegroup with the nodes between the specified ``common``
 and ``heads`` nodes. Depending on the command arguments, the type and content
 of the returned bundle can vary significantly.
 
 The default behavior is for the server to send a raw changegroup version
 ``01`` response.
 
 If the ``bundlecaps`` provided by the client contain a value beginning
 with ``HG2``, a bundle2 will be returned. The bundle2 data may contain
 additional repository data, such as ``pushkey`` namespace values.
 
 heads
 -----
 
 Returns a list of space-delimited hex nodes of repository heads followed
 by a newline. e.g.
 ``a9eeb3adc7ddb5006c088e9eda61791c777cbf7c 31f91a3da534dc849f0d6bfc00a395a97cf218a1\n``
 
 This command does not accept any arguments. The return type is a ``string``.
 
 hello
 -----
 
 Returns lines describing interesting things about the server in an RFC-822
 like format.
 
 Currently, the only line defines the server capabilities. It has the form::
 
     capabilities: <value>
 
 See above for more about the capabilities string.
 
 SSH clients typically issue this command as soon as a connection is
 established.
 
 This command does not accept any arguments. The return type is a ``string``.
 
 This command was introduced in Mercurial 0.9.1 (released July 2006).
 
 listkeys
 --------
 
 List values in a specified ``pushkey`` namespace.
 
 The ``namespace`` argument defines the pushkey namespace to operate on.
 
 The return type is a ``string``. The value is an encoded dictionary of keys.
 
 Key-value pairs are delimited by newlines (``\n``). Within each line, keys and
 values are separated by a tab (``\t``). Keys and values are both strings.
 
 lookup
 ------
 
 Try to resolve a value to a known repository revision.
 
 The ``key`` argument is converted from bytes to an
 ``encoding.localstr`` instance then passed into
 ``localrepository.__getitem__`` in an attempt to resolve it.
 
 The return type is a ``string``.
 
 Upon successful resolution, returns ``1 <hex node>\n``. On failure,
 returns ``0 <error string>\n``. e.g.::
 
    1 273ce12ad8f155317b2c078ec75a4eba507f1fba\n
 
    0 unknown revision 'foo'\n
 
 known
 -----
 
 Determine whether multiple nodes are known.
 
 The ``nodes`` argument is a list of space-delimited hex nodes to check
 for existence.
 
 The return type is ``string``.
 
 Returns a string consisting of ``0``s and ``1``s indicating whether nodes
 are known. If the Nth node specified in the ``nodes`` argument is known,
 a ``1`` will be returned at byte offset N. If the node isn't known, ``0``
 will be present at byte offset N.
 
 There is no trailing newline.
 
 pushkey
 -------
 
 Set a value using the ``pushkey`` protocol.
 
 Accepts arguments ``namespace``, ``key``, ``old``, and ``new``, which
 correspond to the pushkey namespace to operate on, the key within that
 namespace to change, the old value (which may be empty), and the new value.
 All arguments are string types.
 
 The return type is a ``string``. The value depends on the transport protocol.
 
 The SSH version 1 transport sends a string encoded integer followed by a
 newline (``\n``) which indicates operation result. The server may send
 additional output on the ``stderr`` stream that should be displayed to the
 user.
 
 The HTTP version 1 transport sends a string encoded integer followed by a
 newline followed by additional server output that should be displayed to
 the user. This may include output from hooks, etc.
 
 The integer result varies by namespace. ``0`` means an error has occurred
 and there should be additional output to display to the user.
 
 stream_out
 ----------
 
 Obtain *streaming clone* data.
 
 The return type is either a ``string`` or a ``stream``, depending on
 whether the request was fulfilled properly.
 
 A return value of ``1\n`` indicates the server is not configured to serve
 this data. If this is seen by the client, they may not have verified the
 ``stream`` capability is set before making the request.
 
 A return value of ``2\n`` indicates the server was unable to lock the
 repository to generate data.
 
 All other responses are a ``stream`` of bytes. The first line of this data
 contains 2 space-delimited integers corresponding to the path count and
 payload size, respectively::
 
     <path count> <payload size>\n
 
 The ``<payload size>`` is the total size of path data: it does not include
 the size of the per-path header lines.
 
 Following that header are ``<path count>`` entries. Each entry consists of a
 line with metadata followed by raw revlog data. The line consists of::
 
     <store path>\0<size>\n
 
 The ``<store path>`` is the encoded store path of the data that follows.
 ``<size>`` is the amount of data for this store path/revlog that follows the
 newline.
 
 There is no trailer to indicate end of data. Instead, the client should stop
 reading after ``<path count>`` entries are consumed.
 
 unbundle
 --------
 
 Send a bundle containing data (usually changegroup data) to the server.
 
 Accepts the argument ``heads``, which is a space-delimited list of hex nodes
 corresponding to server repository heads observed by the client. This is used
 to detect race conditions and abort push operations before a server performs
 too much work or a client transfers too much data.
 
 The request payload consists of a bundle to be applied to the repository,
 similarly to as if :hg:`unbundle` were called.
 
 In most scenarios, a special ``push response`` type is returned. This type
 contains an integer describing the change in heads as a result of the
 operation. A value of ``0`` indicates nothing changed. ``1`` means the number
 of heads remained the same. Values ``2`` and larger indicate the number of
 added heads minus 1. e.g. ``3`` means 2 heads were added. Negative values
 indicate the number of fewer heads, also off by 1. e.g. ``-2`` means there
 is 1 fewer head.
 
 The encoding of the ``push response`` type varies by transport.
 
 For the SSH version 1 transport, this type is composed of 2 ``string``
 responses: an empty response (``0\n``) followed by the integer result value.
 e.g. ``1\n2``. So the full response might be ``0\n1\n2``.
 
 For the HTTP version 1 transport, the response is a ``string`` type composed
 of an integer result value followed by a newline (``\n``) followed by string
 content holding server output that should be displayed on the client (output
 hooks, etc).
 
 In some cases, the server may respond with a ``bundle2`` bundle. In this
 case, the response type is ``stream``. For the HTTP version 1 transport, the
 response is zlib compressed.
 
 The server may also respond with a generic error type, which contains a string
 indicating the failure.

mercurial/wireprotoserver.py

@@ -1,1017 +1,1043 b''
 # Copyright 21 May 2005 - (c) 2005 Jake Edge <[e-mail]>
 # Copyright 2005-2007 Matt Mackall <[e-mail]>
 #
 # This software may be used and distributed according to the terms of the
 # GNU General Public License version 2 or any later version.
 
 from __future__ import absolute_import
 
 import contextlib
 import struct
 import sys
 import threading
 
 from .i18n import _
 from . import (
     encoding,
     error,
     hook,
     pycompat,
     util,
     wireproto,
     wireprotoframing,
     wireprototypes,
 )
 
 stringio = util.stringio
 
 urlerr = util.urlerr
 urlreq = util.urlreq
 
 HTTP_OK = 200
 
 HGTYPE = 'application/mercurial-0.1'
 HGTYPE2 = 'application/mercurial-0.2'
 HGERRTYPE = 'application/hg-error'
 FRAMINGTYPE = b'application/mercurial-exp-framing-0002'
 
 HTTPV2 = wireprototypes.HTTPV2
 SSHV1 = wireprototypes.SSHV1
 SSHV2 = wireprototypes.SSHV2
 
 def decodevaluefromheaders(req, headerprefix):
     """Decode a long value from multiple HTTP request headers.
 
     Returns the value as a bytes, not a str.
     """
     chunks = []
     i = 1
     while True:
         v = req.headers.get(b'%s-%d' % (headerprefix, i))
         if v is None:
             break
         chunks.append(pycompat.bytesurl(v))
         i += 1
 
     return ''.join(chunks)
 
 class httpv1protocolhandler(wireprototypes.baseprotocolhandler):
     def __init__(self, req, ui, checkperm):
         self._req = req
         self._ui = ui
         self._checkperm = checkperm
 
     @property
     def name(self):
         return 'http-v1'
 
     def getargs(self, args):
         knownargs = self._args()
         data = {}
         keys = args.split()
         for k in keys:
             if k == '*':
                 star = {}
                 for key in knownargs.keys():
                     if key != 'cmd' and key not in keys:
                         star[key] = knownargs[key][0]
                 data['*'] = star
             else:
                 data[k] = knownargs[k][0]
         return [data[k] for k in keys]
 
     def _args(self):
         args = self._req.qsparams.asdictoflists()
         postlen = int(self._req.headers.get(b'X-HgArgs-Post', 0))
         if postlen:
             args.update(urlreq.parseqs(
                 self._req.bodyfh.read(postlen), keep_blank_values=True))
             return args
 
         argvalue = decodevaluefromheaders(self._req, b'X-HgArg')
         args.update(urlreq.parseqs(argvalue, keep_blank_values=True))
         return args
 
     def forwardpayload(self, fp):
         # Existing clients *always* send Content-Length.
         length = int(self._req.headers[b'Content-Length'])
 
         # If httppostargs is used, we need to read Content-Length
         # minus the amount that was consumed by args.
         length -= int(self._req.headers.get(b'X-HgArgs-Post', 0))
         for s in util.filechunkiter(self._req.bodyfh, limit=length):
             fp.write(s)
 
     @contextlib.contextmanager
     def mayberedirectstdio(self):
         oldout = self._ui.fout
         olderr = self._ui.ferr
 
         out = util.stringio()
 
         try:
             self._ui.fout = out
             self._ui.ferr = out
             yield out
         finally:
             self._ui.fout = oldout
             self._ui.ferr = olderr
 
     def client(self):
         return 'remote:%s:%s:%s' % (
             self._req.urlscheme,
             urlreq.quote(self._req.remotehost or ''),
             urlreq.quote(self._req.remoteuser or ''))
 
     def addcapabilities(self, repo, caps):
         caps.append(b'batch')
 
         caps.append('httpheader=%d' %
                     repo.ui.configint('server', 'maxhttpheaderlen'))
         if repo.ui.configbool('experimental', 'httppostargs'):
             caps.append('httppostargs')
 
         # FUTURE advertise 0.2rx once support is implemented
         # FUTURE advertise minrx and mintx after consulting config option
         caps.append('httpmediatype=0.1rx,0.1tx,0.2tx')
 
         compengines = wireproto.supportedcompengines(repo.ui, util.SERVERROLE)
         if compengines:
             comptypes = ','.join(urlreq.quote(e.wireprotosupport().name)
                                  for e in compengines)
             caps.append('compression=%s' % comptypes)
 
         return caps
 
     def checkperm(self, perm):
         return self._checkperm(perm)
 
 # This method exists mostly so that extensions like remotefilelog can
 # disable a kludgey legacy method only over http. As of early 2018,
 # there are no other known users, so with any luck we can discard this
 # hook if remotefilelog becomes a first-party extension.
 def iscmd(cmd):
     return cmd in wireproto.commands
 
 def handlewsgirequest(rctx, req, res, checkperm):
     """Possibly process a wire protocol request.
 
     If the current request is a wire protocol request, the request is
     processed by this function.
 
     ``req`` is a ``parsedrequest`` instance.
     ``res`` is a ``wsgiresponse`` instance.
 
     Returns a bool indicating if the request was serviced. If set, the caller
     should stop processing the request, as a response has already been issued.
     """
     # Avoid cycle involving hg module.
     from .hgweb import common as hgwebcommon
 
     repo = rctx.repo
 
     # HTTP version 1 wire protocol requests are denoted by a "cmd" query
     # string parameter. If it isn't present, this isn't a wire protocol
     # request.
     if 'cmd' not in req.qsparams:
         return False
 
     cmd = req.qsparams['cmd']
 
     # The "cmd" request parameter is used by both the wire protocol and hgweb.
     # While not all wire protocol commands are available for all transports,
     # if we see a "cmd" value that resembles a known wire protocol command, we
     # route it to a protocol handler. This is better than routing possible
     # wire protocol requests to hgweb because it prevents hgweb from using
     # known wire protocol commands and it is less confusing for machine
     # clients.
     if not iscmd(cmd):
         return False
 
     # The "cmd" query string argument is only valid on the root path of the
     # repo. e.g. ``/?cmd=foo``, ``/repo?cmd=foo``. URL paths within the repo
     # like ``/blah?cmd=foo`` are not allowed. So don't recognize the request
     # in this case. We send an HTTP 404 for backwards compatibility reasons.
     if req.dispatchpath:
         res.status = hgwebcommon.statusmessage(404)
         res.headers['Content-Type'] = HGTYPE
         # TODO This is not a good response to issue for this request. This
         # is mostly for BC for now.
         res.setbodybytes('0\n%s\n' % b'Not Found')
         return True
 
     proto = httpv1protocolhandler(req, repo.ui,
                                   lambda perm: checkperm(rctx, req, perm))
 
     # The permissions checker should be the only thing that can raise an
     # ErrorResponse. It is kind of a layer violation to catch an hgweb
     # exception here. So consider refactoring into a exception type that
     # is associated with the wire protocol.
     try:
         _callhttp(repo, req, res, proto, cmd)
     except hgwebcommon.ErrorResponse as e:
         for k, v in e.headers:
             res.headers[k] = v
         res.status = hgwebcommon.statusmessage(e.code, pycompat.bytestr(e))
         # TODO This response body assumes the failed command was
         # "unbundle." That assumption is not always valid.
         res.setbodybytes('0\n%s\n' % pycompat.bytestr(e))
 
     return True
 
 def handlewsgiapirequest(rctx, req, res, checkperm):
     """Handle requests to /api/*."""
     assert req.dispatchparts[0] == b'api'
 
     repo = rctx.repo
 
     # This whole URL space is experimental for now. But we want to
     # reserve the URL space. So, 404 all URLs if the feature isn't enabled.
     if not repo.ui.configbool('experimental', 'web.apiserver'):
         res.status = b'404 Not Found'
         res.headers[b'Content-Type'] = b'text/plain'
         res.setbodybytes(_('Experimental API server endpoint not enabled'))
         return
 
     # The URL space is /api/<protocol>/*. The structure of URLs under varies
     # by <protocol>.
 
     # Registered APIs are made available via config options of the name of
     # the protocol.
     availableapis = set()
     for k, v in API_HANDLERS.items():
         section, option = v['config']
         if repo.ui.configbool(section, option):
             availableapis.add(k)
 
     # Requests to /api/ list available APIs.
     if req.dispatchparts == [b'api']:
         res.status = b'200 OK'
         res.headers[b'Content-Type'] = b'text/plain'
         lines = [_('APIs can be accessed at /api/<name>, where <name> can be '
                    'one of the following:\n')]
         if availableapis:
             lines.extend(sorted(availableapis))
         else:
             lines.append(_('(no available APIs)\n'))
         res.setbodybytes(b'\n'.join(lines))
         return
 
     proto = req.dispatchparts[1]
 
     if proto not in API_HANDLERS:
         res.status = b'404 Not Found'
         res.headers[b'Content-Type'] = b'text/plain'
         res.setbodybytes(_('Unknown API: %s\nKnown APIs: %s') % (
             proto, b', '.join(sorted(availableapis))))
         return
 
     if proto not in availableapis:
         res.status = b'404 Not Found'
         res.headers[b'Content-Type'] = b'text/plain'
         res.setbodybytes(_('API %s not enabled\n') % proto)
         return
 
     API_HANDLERS[proto]['handler'](rctx, req, res, checkperm,
                                    req.dispatchparts[2:])
 
 def _handlehttpv2request(rctx, req, res, checkperm, urlparts):
     from .hgweb import common as hgwebcommon
 
     # URL space looks like: <permissions>/<command>, where <permission> can
     # be ``ro`` or ``rw`` to signal read-only or read-write, respectively.
 
     # Root URL does nothing meaningful... yet.
     if not urlparts:
         res.status = b'200 OK'
         res.headers[b'Content-Type'] = b'text/plain'
         res.setbodybytes(_('HTTP version 2 API handler'))
         return
 
     if len(urlparts) == 1:
         res.status = b'404 Not Found'
         res.headers[b'Content-Type'] = b'text/plain'
         res.setbodybytes(_('do not know how to process %s\n') %
                          req.dispatchpath)
         return
 
     permission, command = urlparts[0:2]
 
     if permission not in (b'ro', b'rw'):
         res.status = b'404 Not Found'
         res.headers[b'Content-Type'] = b'text/plain'
         res.setbodybytes(_('unknown permission: %s') % permission)
         return
 
     if req.method != 'POST':
         res.status = b'405 Method Not Allowed'
         res.headers[b'Allow'] = b'POST'
         res.setbodybytes(_('commands require POST requests'))
         return
 
     # At some point we'll want to use our own API instead of recycling the
     # behavior of version 1 of the wire protocol...
     # TODO return reasonable responses - not responses that overload the
     # HTTP status line message for error reporting.
     try:
         checkperm(rctx, req, 'pull' if permission == b'ro' else 'push')
     except hgwebcommon.ErrorResponse as e:
         res.status = hgwebcommon.statusmessage(e.code, pycompat.bytestr(e))
         for k, v in e.headers:
             res.headers[k] = v
         res.setbodybytes('permission denied')
         return
 
     # We have a special endpoint to reflect the request back at the client.
     if command == b'debugreflect':
         _processhttpv2reflectrequest(rctx.repo.ui, rctx.repo, req, res)
         return
 
-    if command not in wireproto.commands:
+    # Extra commands that we handle that aren't really wire protocol
+    # commands. Think extra hard before making this hackery available to
+    # extension.
+    extracommands = {'multirequest'}
+
+    if command not in wireproto.commands and command not in extracommands:
         res.status = b'404 Not Found'
         res.headers[b'Content-Type'] = b'text/plain'
         res.setbodybytes(_('unknown wire protocol command: %s\n') % command)
         return
 
     repo = rctx.repo
     ui = repo.ui
 
     proto = httpv2protocolhandler(req, ui)
 
-    if not wireproto.commands.commandavailable(command, proto):
+    if (not wireproto.commands.commandavailable(command, proto)
+        and command not in extracommands):
         res.status = b'404 Not Found'
         res.headers[b'Content-Type'] = b'text/plain'
         res.setbodybytes(_('invalid wire protocol command: %s') % command)
         return
 
     if req.headers.get(b'Accept') != FRAMINGTYPE:
         res.status = b'406 Not Acceptable'
         res.headers[b'Content-Type'] = b'text/plain'
         res.setbodybytes(_('client MUST specify Accept header with value: %s\n')
                            % FRAMINGTYPE)
         return
 
     if req.headers.get(b'Content-Type') != FRAMINGTYPE:
         res.status = b'415 Unsupported Media Type'
         # TODO we should send a response with appropriate media type,
         # since client does Accept it.
         res.headers[b'Content-Type'] = b'text/plain'
         res.setbodybytes(_('client MUST send Content-Type header with '
                            'value: %s\n') % FRAMINGTYPE)
         return
 
     _processhttpv2request(ui, repo, req, res, permission, command, proto)
 
 def _processhttpv2reflectrequest(ui, repo, req, res):
     """Reads unified frame protocol request and dumps out state to client.
 
     This special endpoint can be used to help debug the wire protocol.
 
     Instead of routing the request through the normal dispatch mechanism,
     we instead read all frames, decode them, and feed them into our state
     tracker. We then dump the log of all that activity back out to the
     client.
     """
     import json
 
     # Reflection APIs have a history of being abused, accidentally disclosing
     # sensitive data, etc. So we have a config knob.
     if not ui.configbool('experimental', 'web.api.debugreflect'):
         res.status = b'404 Not Found'
         res.headers[b'Content-Type'] = b'text/plain'
         res.setbodybytes(_('debugreflect service not available'))
         return
 
     # We assume we have a unified framing protocol request body.
 
     reactor = wireprotoframing.serverreactor()
     states = []
 
     while True:
         frame = wireprotoframing.readframe(req.bodyfh)
 
         if not frame:
             states.append(b'received: <no frame>')
             break
 
         requestid, frametype, frameflags, payload = frame
         states.append(b'received: %d %d %d %s' % (frametype, frameflags,
                                                   requestid, payload))
 
         action, meta = reactor.onframerecv(requestid, frametype, frameflags,
                                            payload)
         states.append(json.dumps((action, meta), sort_keys=True,
                                  separators=(', ', ': ')))
 
     action, meta = reactor.oninputeof()
     meta['action'] = action
     states.append(json.dumps(meta, sort_keys=True, separators=(', ',': ')))
 
     res.status = b'200 OK'
     res.headers[b'Content-Type'] = b'text/plain'
     res.setbodybytes(b'\n'.join(states))
 
 def _processhttpv2request(ui, repo, req, res, authedperm, reqcommand, proto):
     """Post-validation handler for HTTPv2 requests.
 
     Called when the HTTP request contains unified frame-based protocol
     frames for evaluation.
     """
     # TODO Some HTTP clients are full duplex and can receive data before
     # the entire request is transmitted. Figure out a way to indicate support
     # for that so we can opt into full duplex mode.
     reactor = wireprotoframing.serverreactor(deferoutput=True)
     seencommand = False
 
     while True:
         frame = wireprotoframing.readframe(req.bodyfh)
         if not frame:
             break
 
         action, meta = reactor.onframerecv(*frame)
 
         if action == 'wantframe':
             # Need more data before we can do anything.
             continue
         elif action == 'runcommand':
-            # We currently only support running a single command per
-            # HTTP request.
-            if seencommand:
-                # TODO define proper error mechanism.
-                res.status = b'200 OK'
-                res.headers[b'Content-Type'] = b'text/plain'
-                res.setbodybytes(_('support for multiple commands per request '
-                                   'not yet implemented'))
+            sentoutput = _httpv2runcommand(ui, repo, req, res, authedperm,
+                                           reqcommand, reactor, meta,
+                                           issubsequent=seencommand)
+
+            if sentoutput:
                 return
 
-            _httpv2runcommand(ui, repo, req, res, authedperm, reqcommand,
-                              reactor, meta)
+            seencommand = True
 
         elif action == 'error':
             # TODO define proper error mechanism.
             res.status = b'200 OK'
             res.headers[b'Content-Type'] = b'text/plain'
             res.setbodybytes(meta['message'] + b'\n')
             return
         else:
             raise error.ProgrammingError(
                 'unhandled action from frame processor: %s' % action)
 
     action, meta = reactor.oninputeof()
     if action == 'sendframes':
         # We assume we haven't started sending the response yet. If we're
         # wrong, the response type will raise an exception.
         res.status = b'200 OK'
         res.headers[b'Content-Type'] = FRAMINGTYPE
         res.setbodygen(meta['framegen'])
     elif action == 'noop':
         pass
     else:
         raise error.ProgrammingError('unhandled action from frame processor: %s'
                                      % action)
 
 def _httpv2runcommand(ui, repo, req, res, authedperm, reqcommand, reactor,
-                      command):
+                      command, issubsequent):
     """Dispatch a wire protocol command made from HTTPv2 requests.
 
     The authenticated permission (``authedperm``) along with the original
     command from the URL (``reqcommand``) are passed in.
     """
     # We already validated that the session has permissions to perform the
     # actions in ``authedperm``. In the unified frame protocol, the canonical
     # command to run is expressed in a frame. However, the URL also requested
     # to run a specific command. We need to be careful that the command we
     # run doesn't have permissions requirements greater than what was granted
     # by ``authedperm``.
     #
-    # For now, this is no big deal, as we only allow a single command per
-    # request and that command must match the command in the URL. But when
-    # things change, we need to watch out...
-    if reqcommand != command['command']:
-        # TODO define proper error mechanism
-        res.status = b'200 OK'
-        res.headers[b'Content-Type'] = b'text/plain'
-        res.setbodybytes(_('command in frame must match command in URL'))
-        return
-
-    # TODO once we get rid of the command==URL restriction, we'll need to
-    # revalidate command validity and auth here. checkperm,
-    # wireproto.commands.commandavailable(), etc.
+    # Our rule for this is we only allow one command per HTTP request and
+    # that command must match the command in the URL. However, we make
+    # an exception for the ``multirequest`` URL. This URL is allowed to
+    # execute multiple commands. We double check permissions of each command
+    # as it is invoked to ensure there is no privilege escalation.
+    # TODO consider allowing multiple commands to regular command URLs
+    # iff each command is the same.
 
     proto = httpv2protocolhandler(req, ui, args=command['args'])
-    assert wireproto.commands.commandavailable(command['command'], proto)
-    wirecommand = wireproto.commands[command['command']]
 
-    assert authedperm in (b'ro', b'rw')
-    assert wirecommand.permission in ('push', 'pull')
+    if reqcommand == b'multirequest':
+        if not wireproto.commands.commandavailable(command['command'], proto):
+            # TODO proper error mechanism
+            res.status = b'200 OK'
+            res.headers[b'Content-Type'] = b'text/plain'
+            res.setbodybytes(_('wire protocol command not available: %s') %
+                             command['command'])
+            return True
+
+        assert authedperm in (b'ro', b'rw')
+        wirecommand = wireproto.commands[command['command']]
+        assert wirecommand.permission in ('push', 'pull')
 
-    # We already checked this as part of the URL==command check, but
-    # permissions are important, so do it again.
-    if authedperm == b'ro':
-        assert wirecommand.permission == 'pull'
-    elif authedperm == b'rw':
-        # We are allowed to access read-only commands under the rw URL.
-        assert wirecommand.permission in ('push', 'pull')
+        if authedperm == b'ro' and wirecommand.permission != 'pull':
+            # TODO proper error mechanism
+            res.status = b'403 Forbidden'
+            res.headers[b'Content-Type'] = b'text/plain'
+            res.setbodybytes(_('insufficient permissions to execute '
+                               'command: %s') % command['command'])
+            return True
+
+        # TODO should we also call checkperm() here? Maybe not if we're going
+        # to overhaul that API. The granted scope from the URL check should
+        # be good enough.
+
+    else:
+        # Don't allow multiple commands outside of ``multirequest`` URL.
+        if issubsequent:
+            # TODO proper error mechanism
+            res.status = b'200 OK'
+            res.headers[b'Content-Type'] = b'text/plain'
+            res.setbodybytes(_('multiple commands cannot be issued to this '
+                               'URL'))
+            return True
+
+        if reqcommand != command['command']:
+            # TODO define proper error mechanism
+            res.status = b'200 OK'
+            res.headers[b'Content-Type'] = b'text/plain'
+            res.setbodybytes(_('command in frame must match command in URL'))
+            return True
 
     rsp = wireproto.dispatch(repo, proto, command['command'])
 
     res.status = b'200 OK'
     res.headers[b'Content-Type'] = FRAMINGTYPE
 
     if isinstance(rsp, wireprototypes.bytesresponse):
         action, meta = reactor.onbytesresponseready(command['requestid'],
                                                     rsp.data)
     else:
         action, meta = reactor.onapplicationerror(
             _('unhandled response type from wire proto command'))
 
     if action == 'sendframes':
         res.setbodygen(meta['framegen'])
+        return True
     elif action == 'noop':
         pass
     else:
         raise error.ProgrammingError('unhandled event from reactor: %s' %
                                      action)
 
 # Maps API name to metadata so custom API can be registered.
 API_HANDLERS = {
     HTTPV2: {
         'config': ('experimental', 'web.api.http-v2'),
         'handler': _handlehttpv2request,
     },
 }
 
 class httpv2protocolhandler(wireprototypes.baseprotocolhandler):
     def __init__(self, req, ui, args=None):
         self._req = req
         self._ui = ui
         self._args = args
 
     @property
     def name(self):
         return HTTPV2
 
     def getargs(self, args):
         data = {}
         for k in args.split():
             if k == '*':
                 raise NotImplementedError('do not support * args')
             else:
                 data[k] = self._args[k]
 
         return [data[k] for k in args.split()]
 
     def forwardpayload(self, fp):
         raise NotImplementedError
 
     @contextlib.contextmanager
     def mayberedirectstdio(self):
         raise NotImplementedError
 
     def client(self):
         raise NotImplementedError
 
     def addcapabilities(self, repo, caps):
         return caps
 
     def checkperm(self, perm):
         raise NotImplementedError
 
 def _httpresponsetype(ui, req, prefer_uncompressed):
     """Determine the appropriate response type and compression settings.
 
     Returns a tuple of (mediatype, compengine, engineopts).
     """
     # Determine the response media type and compression engine based
     # on the request parameters.
     protocaps = decodevaluefromheaders(req, 'X-HgProto').split(' ')
 
     if '0.2' in protocaps:
         # All clients are expected to support uncompressed data.
         if prefer_uncompressed:
             return HGTYPE2, util._noopengine(), {}
 
         # Default as defined by wire protocol spec.
         compformats = ['zlib', 'none']
         for cap in protocaps:
             if cap.startswith('comp='):
                 compformats = cap[5:].split(',')
                 break
 
         # Now find an agreed upon compression format.
         for engine in wireproto.supportedcompengines(ui, util.SERVERROLE):
             if engine.wireprotosupport().name in compformats:
                 opts = {}
                 level = ui.configint('server', '%slevel' % engine.name())
                 if level is not None:
                     opts['level'] = level
 
                 return HGTYPE2, engine, opts
 
         # No mutually supported compression format. Fall back to the
         # legacy protocol.
 
     # Don't allow untrusted settings because disabling compression or
     # setting a very high compression level could lead to flooding
     # the server's network or CPU.
     opts = {'level': ui.configint('server', 'zliblevel')}
     return HGTYPE, util.compengines['zlib'], opts
 
 def _callhttp(repo, req, res, proto, cmd):
     # Avoid cycle involving hg module.
     from .hgweb import common as hgwebcommon
 
     def genversion2(gen, engine, engineopts):
         # application/mercurial-0.2 always sends a payload header
         # identifying the compression engine.
         name = engine.wireprotosupport().name
         assert 0 < len(name) < 256
         yield struct.pack('B', len(name))
         yield name
 
         for chunk in gen:
             yield chunk
 
     def setresponse(code, contenttype, bodybytes=None, bodygen=None):
         if code == HTTP_OK:
             res.status = '200 Script output follows'
         else:
             res.status = hgwebcommon.statusmessage(code)
 
         res.headers['Content-Type'] = contenttype
 
         if bodybytes is not None:
             res.setbodybytes(bodybytes)
         if bodygen is not None:
             res.setbodygen(bodygen)
 
     if not wireproto.commands.commandavailable(cmd, proto):
         setresponse(HTTP_OK, HGERRTYPE,
                     _('requested wire protocol command is not available over '
                       'HTTP'))
         return
 
     proto.checkperm(wireproto.commands[cmd].permission)
 
     rsp = wireproto.dispatch(repo, proto, cmd)
 
     if isinstance(rsp, bytes):
         setresponse(HTTP_OK, HGTYPE, bodybytes=rsp)
     elif isinstance(rsp, wireprototypes.bytesresponse):
         setresponse(HTTP_OK, HGTYPE, bodybytes=rsp.data)
     elif isinstance(rsp, wireprototypes.streamreslegacy):
         setresponse(HTTP_OK, HGTYPE, bodygen=rsp.gen)
     elif isinstance(rsp, wireprototypes.streamres):
         gen = rsp.gen
 
         # This code for compression should not be streamres specific. It
         # is here because we only compress streamres at the moment.
         mediatype, engine, engineopts = _httpresponsetype(
             repo.ui, req, rsp.prefer_uncompressed)
         gen = engine.compressstream(gen, engineopts)
 
         if mediatype == HGTYPE2:
             gen = genversion2(gen, engine, engineopts)
 
         setresponse(HTTP_OK, mediatype, bodygen=gen)
     elif isinstance(rsp, wireprototypes.pushres):
         rsp = '%d\n%s' % (rsp.res, rsp.output)
         setresponse(HTTP_OK, HGTYPE, bodybytes=rsp)
     elif isinstance(rsp, wireprototypes.pusherr):
         rsp = '0\n%s\n' % rsp.res
         res.drain = True
         setresponse(HTTP_OK, HGTYPE, bodybytes=rsp)
     elif isinstance(rsp, wireprototypes.ooberror):
         setresponse(HTTP_OK, HGERRTYPE, bodybytes=rsp.message)
     else:
         raise error.ProgrammingError('hgweb.protocol internal failure', rsp)
 
 def _sshv1respondbytes(fout, value):
     """Send a bytes response for protocol version 1."""
     fout.write('%d\n' % len(value))
     fout.write(value)
     fout.flush()
 
 def _sshv1respondstream(fout, source):
     write = fout.write
     for chunk in source.gen:
         write(chunk)
     fout.flush()
 
 def _sshv1respondooberror(fout, ferr, rsp):
     ferr.write(b'%s\n-\n' % rsp)
     ferr.flush()
     fout.write(b'\n')
     fout.flush()
 
 class sshv1protocolhandler(wireprototypes.baseprotocolhandler):
     """Handler for requests services via version 1 of SSH protocol."""
     def __init__(self, ui, fin, fout):
         self._ui = ui
         self._fin = fin
         self._fout = fout
 
     @property
     def name(self):
         return wireprototypes.SSHV1
 
     def getargs(self, args):
         data = {}
         keys = args.split()
         for n in xrange(len(keys)):
             argline = self._fin.readline()[:-1]
             arg, l = argline.split()
             if arg not in keys:
                 raise error.Abort(_("unexpected parameter %r") % arg)
             if arg == '*':
                 star = {}
                 for k in xrange(int(l)):
                     argline = self._fin.readline()[:-1]
                     arg, l = argline.split()
                     val = self._fin.read(int(l))
                     star[arg] = val
                 data['*'] = star
             else:
                 val = self._fin.read(int(l))
                 data[arg] = val
         return [data[k] for k in keys]
 
     def forwardpayload(self, fpout):
         # We initially send an empty response. This tells the client it is
         # OK to start sending data. If a client sees any other response, it
         # interprets it as an error.
         _sshv1respondbytes(self._fout, b'')
 
         # The file is in the form:
         #
         # <chunk size>\n<chunk>
         # ...
         # 0\n
         count = int(self._fin.readline())
         while count:
             fpout.write(self._fin.read(count))
             count = int(self._fin.readline())
 
     @contextlib.contextmanager
     def mayberedirectstdio(self):
         yield None
 
     def client(self):
         client = encoding.environ.get('SSH_CLIENT', '').split(' ', 1)[0]
         return 'remote:ssh:' + client
 
     def addcapabilities(self, repo, caps):
         caps.append(b'batch')
         return caps
 
     def checkperm(self, perm):
         pass
 
 class sshv2protocolhandler(sshv1protocolhandler):
     """Protocol handler for version 2 of the SSH protocol."""
 
     @property
     def name(self):
         return wireprototypes.SSHV2
 
 def _runsshserver(ui, repo, fin, fout, ev):
     # This function operates like a state machine of sorts. The following
     # states are defined:
     #
     # protov1-serving
     #    Server is in protocol version 1 serving mode. Commands arrive on
     #    new lines. These commands are processed in this state, one command
     #    after the other.
     #
     # protov2-serving
     #    Server is in protocol version 2 serving mode.
     #
     # upgrade-initial
     #    The server is going to process an upgrade request.
     #
     # upgrade-v2-filter-legacy-handshake
     #    The protocol is being upgraded to version 2. The server is expecting
     #    the legacy handshake from version 1.
     #
     # upgrade-v2-finish
     #    The upgrade to version 2 of the protocol is imminent.
     #
     # shutdown
     #    The server is shutting down, possibly in reaction to a client event.
     #
     # And here are their transitions:
     #
     # protov1-serving -> shutdown
     #    When server receives an empty request or encounters another
     #    error.
     #
     # protov1-serving -> upgrade-initial
     #    An upgrade request line was seen.
     #
     # upgrade-initial -> upgrade-v2-filter-legacy-handshake
     #    Upgrade to version 2 in progress. Server is expecting to
     #    process a legacy handshake.
     #
     # upgrade-v2-filter-legacy-handshake -> shutdown
     #    Client did not fulfill upgrade handshake requirements.
     #
     # upgrade-v2-filter-legacy-handshake -> upgrade-v2-finish
     #    Client fulfilled version 2 upgrade requirements. Finishing that
     #    upgrade.
     #
     # upgrade-v2-finish -> protov2-serving
     #    Protocol upgrade to version 2 complete. Server can now speak protocol
     #    version 2.
     #
     # protov2-serving -> protov1-serving
     #    Ths happens by default since protocol version 2 is the same as
     #    version 1 except for the handshake.
 
     state = 'protov1-serving'
     proto = sshv1protocolhandler(ui, fin, fout)
     protoswitched = False
 
     while not ev.is_set():
         if state == 'protov1-serving':
             # Commands are issued on new lines.
             request = fin.readline()[:-1]
 
             # Empty lines signal to terminate the connection.
             if not request:
                 state = 'shutdown'
                 continue
 
             # It looks like a protocol upgrade request. Transition state to
             # handle it.
             if request.startswith(b'upgrade '):
                 if protoswitched:
                     _sshv1respondooberror(fout, ui.ferr,
                                           b'cannot upgrade protocols multiple '
                                           b'times')
                     state = 'shutdown'
                     continue
 
                 state = 'upgrade-initial'
                 continue
 
             available = wireproto.commands.commandavailable(request, proto)
 
             # This command isn't available. Send an empty response and go
             # back to waiting for a new command.
             if not available:
                 _sshv1respondbytes(fout, b'')
                 continue
 
             rsp = wireproto.dispatch(repo, proto, request)
 
             if isinstance(rsp, bytes):
                 _sshv1respondbytes(fout, rsp)
             elif isinstance(rsp, wireprototypes.bytesresponse):
                 _sshv1respondbytes(fout, rsp.data)
             elif isinstance(rsp, wireprototypes.streamres):
                 _sshv1respondstream(fout, rsp)
             elif isinstance(rsp, wireprototypes.streamreslegacy):
                 _sshv1respondstream(fout, rsp)
             elif isinstance(rsp, wireprototypes.pushres):
                 _sshv1respondbytes(fout, b'')
                 _sshv1respondbytes(fout, b'%d' % rsp.res)
             elif isinstance(rsp, wireprototypes.pusherr):
                 _sshv1respondbytes(fout, rsp.res)
             elif isinstance(rsp, wireprototypes.ooberror):
                 _sshv1respondooberror(fout, ui.ferr, rsp.message)
             else:
                 raise error.ProgrammingError('unhandled response type from '
                                              'wire protocol command: %s' % rsp)
 
         # For now, protocol version 2 serving just goes back to version 1.
         elif state == 'protov2-serving':
             state = 'protov1-serving'
             continue
 
         elif state == 'upgrade-initial':
             # We should never transition into this state if we've switched
             # protocols.
             assert not protoswitched
             assert proto.name == wireprototypes.SSHV1
 
             # Expected: upgrade <token> <capabilities>
             # If we get something else, the request is malformed. It could be
             # from a future client that has altered the upgrade line content.
             # We treat this as an unknown command.
             try:
                 token, caps = request.split(b' ')[1:]
             except ValueError:
                 _sshv1respondbytes(fout, b'')
                 state = 'protov1-serving'
                 continue
 
             # Send empty response if we don't support upgrading protocols.
             if not ui.configbool('experimental', 'sshserver.support-v2'):
                 _sshv1respondbytes(fout, b'')
                 state = 'protov1-serving'
                 continue
 
             try:
                 caps = urlreq.parseqs(caps)
             except ValueError:
                 _sshv1respondbytes(fout, b'')
                 state = 'protov1-serving'
                 continue
 
             # We don't see an upgrade request to protocol version 2. Ignore
             # the upgrade request.
             wantedprotos = caps.get(b'proto', [b''])[0]
             if SSHV2 not in wantedprotos:
                 _sshv1respondbytes(fout, b'')
                 state = 'protov1-serving'
                 continue
 
             # It looks like we can honor this upgrade request to protocol 2.
             # Filter the rest of the handshake protocol request lines.
             state = 'upgrade-v2-filter-legacy-handshake'
             continue
 
         elif state == 'upgrade-v2-filter-legacy-handshake':
             # Client should have sent legacy handshake after an ``upgrade``
             # request. Expected lines:
             #
             #    hello
             #    between
             #    pairs 81
             #    0000...-0000...
 
             ok = True
             for line in (b'hello', b'between', b'pairs 81'):
                 request = fin.readline()[:-1]
 
                 if request != line:
                     _sshv1respondooberror(fout, ui.ferr,
                                           b'malformed handshake protocol: '
                                           b'missing %s' % line)
                     ok = False
                     state = 'shutdown'
                     break
 
             if not ok:
                 continue
 
             request = fin.read(81)
             if request != b'%s-%s' % (b'0' * 40, b'0' * 40):
                 _sshv1respondooberror(fout, ui.ferr,
                                       b'malformed handshake protocol: '
                                       b'missing between argument value')
                 state = 'shutdown'
                 continue
 
             state = 'upgrade-v2-finish'
             continue
 
         elif state == 'upgrade-v2-finish':
             # Send the upgrade response.
             fout.write(b'upgraded %s %s\n' % (token, SSHV2))
             servercaps = wireproto.capabilities(repo, proto)
             rsp = b'capabilities: %s' % servercaps.data
             fout.write(b'%d\n%s\n' % (len(rsp), rsp))
             fout.flush()
 
             proto = sshv2protocolhandler(ui, fin, fout)
             protoswitched = True
 
             state = 'protov2-serving'
             continue
 
         elif state == 'shutdown':
             break
 
         else:
             raise error.ProgrammingError('unhandled ssh server state: %s' %
                                          state)
 
 class sshserver(object):
     def __init__(self, ui, repo, logfh=None):
         self._ui = ui
         self._repo = repo
         self._fin = ui.fin
         self._fout = ui.fout
 
         # Log write I/O to stdout and stderr if configured.
         if logfh:
             self._fout = util.makeloggingfileobject(
                 logfh, self._fout, 'o', logdata=True)
             ui.ferr = util.makeloggingfileobject(
                 logfh, ui.ferr, 'e', logdata=True)
 
         hook.redirect(True)
         ui.fout = repo.ui.fout = ui.ferr
 
         # Prevent insertion/deletion of CRs
         util.setbinary(self._fin)
         util.setbinary(self._fout)
 
     def serve_forever(self):
         self.serveuntil(threading.Event())
         sys.exit(0)
 
     def serveuntil(self, ev):
         """Serve until a threading.Event is set."""
         _runsshserver(self._ui, self._repo, self._fin, self._fout, ev)

tests/test-http-api-httpv2.t

@@ -1,415 +1,564 b''
   $ HTTPV2=exp-http-v2-0001
   $ MEDIATYPE=application/mercurial-exp-framing-0002
 
   $ send() {
   >   hg --verbose debugwireproto --peer raw http://$LOCALIP:$HGPORT/
   > }
 
   $ cat > dummycommands.py << EOF
   > from mercurial import wireprototypes, wireproto
   > @wireproto.wireprotocommand('customreadonly', permission='pull')
   > def customreadonly(repo, proto):
   >     return wireprototypes.bytesresponse(b'customreadonly bytes response')
   > @wireproto.wireprotocommand('customreadwrite', permission='push')
   > def customreadwrite(repo, proto):
   >     return wireprototypes.bytesresponse(b'customreadwrite bytes response')
   > EOF
 
   $ cat >> $HGRCPATH << EOF
   > [extensions]
   > dummycommands = $TESTTMP/dummycommands.py
   > EOF
 
   $ hg init server
   $ cat > server/.hg/hgrc << EOF
   > [experimental]
   > web.apiserver = true
   > EOF
   $ hg -R server serve -p $HGPORT -d --pid-file hg.pid
   $ cat hg.pid > $DAEMON_PIDS
 
 HTTP v2 protocol not enabled by default
 
   $ send << EOF
   > httprequest GET api/$HTTPV2
   >     user-agent: test
   > EOF
   using raw connection to peer
   s>     GET /api/exp-http-v2-0001 HTTP/1.1\r\n
   s>     Accept-Encoding: identity\r\n
   s>     user-agent: test\r\n
   s>     host: $LOCALIP:$HGPORT\r\n (glob)
   s>     \r\n
   s> makefile('rb', None)
   s>     HTTP/1.1 404 Not Found\r\n
   s>     Server: testing stub value\r\n
   s>     Date: $HTTP_DATE$\r\n
   s>     Content-Type: text/plain\r\n
   s>     Content-Length: 33\r\n
   s>     \r\n
   s>     API exp-http-v2-0001 not enabled\n
 
 Restart server with support for HTTP v2 API
 
   $ killdaemons.py
   $ cat > server/.hg/hgrc << EOF
   > [experimental]
   > web.apiserver = true
   > web.api.http-v2 = true
   > EOF
 
   $ hg -R server serve -p $HGPORT -d --pid-file hg.pid
   $ cat hg.pid > $DAEMON_PIDS
 
 Request to unknown command yields 404
 
   $ send << EOF
   > httprequest POST api/$HTTPV2/ro/badcommand
   >     user-agent: test
   > EOF
   using raw connection to peer
   s>     POST /api/exp-http-v2-0001/ro/badcommand HTTP/1.1\r\n
   s>     Accept-Encoding: identity\r\n
   s>     user-agent: test\r\n
   s>     host: $LOCALIP:$HGPORT\r\n (glob)
   s>     \r\n
   s> makefile('rb', None)
   s>     HTTP/1.1 404 Not Found\r\n
   s>     Server: testing stub value\r\n
   s>     Date: $HTTP_DATE$\r\n
   s>     Content-Type: text/plain\r\n
   s>     Content-Length: 42\r\n
   s>     \r\n
   s>     unknown wire protocol command: badcommand\n
 
 GET to read-only command yields a 405
 
   $ send << EOF
   > httprequest GET api/$HTTPV2/ro/customreadonly
   >     user-agent: test
   > EOF
   using raw connection to peer
   s>     GET /api/exp-http-v2-0001/ro/customreadonly HTTP/1.1\r\n
   s>     Accept-Encoding: identity\r\n
   s>     user-agent: test\r\n
   s>     host: $LOCALIP:$HGPORT\r\n (glob)
   s>     \r\n
   s> makefile('rb', None)
   s>     HTTP/1.1 405 Method Not Allowed\r\n
   s>     Server: testing stub value\r\n
   s>     Date: $HTTP_DATE$\r\n
   s>     Allow: POST\r\n
   s>     Content-Length: 30\r\n
   s>     \r\n
   s>     commands require POST requests
 
 Missing Accept header results in 406
 
   $ send << EOF
   > httprequest POST api/$HTTPV2/ro/customreadonly
   >     user-agent: test
   > EOF
   using raw connection to peer
   s>     POST /api/exp-http-v2-0001/ro/customreadonly HTTP/1.1\r\n
   s>     Accept-Encoding: identity\r\n
   s>     user-agent: test\r\n
   s>     host: $LOCALIP:$HGPORT\r\n (glob)
   s>     \r\n
   s> makefile('rb', None)
   s>     HTTP/1.1 406 Not Acceptable\r\n
   s>     Server: testing stub value\r\n
   s>     Date: $HTTP_DATE$\r\n
   s>     Content-Type: text/plain\r\n
   s>     Content-Length: 85\r\n
   s>     \r\n
   s>     client MUST specify Accept header with value: application/mercurial-exp-framing-0002\n
 
 Bad Accept header results in 406
 
   $ send << EOF
   > httprequest POST api/$HTTPV2/ro/customreadonly
   >     accept: invalid
   >     user-agent: test
   > EOF
   using raw connection to peer
   s>     POST /api/exp-http-v2-0001/ro/customreadonly HTTP/1.1\r\n
   s>     Accept-Encoding: identity\r\n
   s>     accept: invalid\r\n
   s>     user-agent: test\r\n
   s>     host: $LOCALIP:$HGPORT\r\n (glob)
   s>     \r\n
   s> makefile('rb', None)
   s>     HTTP/1.1 406 Not Acceptable\r\n
   s>     Server: testing stub value\r\n
   s>     Date: $HTTP_DATE$\r\n
   s>     Content-Type: text/plain\r\n
   s>     Content-Length: 85\r\n
   s>     \r\n
   s>     client MUST specify Accept header with value: application/mercurial-exp-framing-0002\n
 
 Bad Content-Type header results in 415
 
   $ send << EOF
   > httprequest POST api/$HTTPV2/ro/customreadonly
   >     accept: $MEDIATYPE
   >     user-agent: test
   >     content-type: badmedia
   > EOF
   using raw connection to peer
   s>     POST /api/exp-http-v2-0001/ro/customreadonly HTTP/1.1\r\n
   s>     Accept-Encoding: identity\r\n
   s>     accept: application/mercurial-exp-framing-0002\r\n
   s>     content-type: badmedia\r\n
   s>     user-agent: test\r\n
   s>     host: $LOCALIP:$HGPORT\r\n (glob)
   s>     \r\n
   s> makefile('rb', None)
   s>     HTTP/1.1 415 Unsupported Media Type\r\n
   s>     Server: testing stub value\r\n
   s>     Date: $HTTP_DATE$\r\n
   s>     Content-Type: text/plain\r\n
   s>     Content-Length: 88\r\n
   s>     \r\n
   s>     client MUST send Content-Type header with value: application/mercurial-exp-framing-0002\n
 
 Request to read-only command works out of the box
 
   $ send << EOF
   > httprequest POST api/$HTTPV2/ro/customreadonly
   >     accept: $MEDIATYPE
   >     content-type: $MEDIATYPE
   >     user-agent: test
   >     frame 1 command-name eos customreadonly
   > EOF
   using raw connection to peer
   s>     POST /api/exp-http-v2-0001/ro/customreadonly HTTP/1.1\r\n
   s>     Accept-Encoding: identity\r\n
   s>     accept: application/mercurial-exp-framing-0002\r\n
   s>     content-type: application/mercurial-exp-framing-0002\r\n
   s>     user-agent: test\r\n
   s>     *\r\n (glob)
   s>     host: $LOCALIP:$HGPORT\r\n (glob)
   s>     \r\n
   s>     \x0e\x00\x00\x01\x00\x11customreadonly
   s> makefile('rb', None)
   s>     HTTP/1.1 200 OK\r\n
   s>     Server: testing stub value\r\n
   s>     Date: $HTTP_DATE$\r\n
   s>     Content-Type: application/mercurial-exp-framing-0002\r\n
   s>     Transfer-Encoding: chunked\r\n
   s>     \r\n
   s>     23\r\n
   s>     \x1d\x00\x00\x01\x00Bcustomreadonly bytes response
   s>     \r\n
   s>     0\r\n
   s>     \r\n
 
 Request to read-write command fails because server is read-only by default
 
 GET to read-write request yields 405
 
   $ send << EOF
   > httprequest GET api/$HTTPV2/rw/customreadonly
   >     user-agent: test
   > EOF
   using raw connection to peer
   s>     GET /api/exp-http-v2-0001/rw/customreadonly HTTP/1.1\r\n
   s>     Accept-Encoding: identity\r\n
   s>     user-agent: test\r\n
   s>     host: $LOCALIP:$HGPORT\r\n (glob)
   s>     \r\n
   s> makefile('rb', None)
   s>     HTTP/1.1 405 Method Not Allowed\r\n
   s>     Server: testing stub value\r\n
   s>     Date: $HTTP_DATE$\r\n
   s>     Allow: POST\r\n
   s>     Content-Length: 30\r\n
   s>     \r\n
   s>     commands require POST requests
 
 Even for unknown commands
 
   $ send << EOF
   > httprequest GET api/$HTTPV2/rw/badcommand
   >     user-agent: test
   > EOF
   using raw connection to peer
   s>     GET /api/exp-http-v2-0001/rw/badcommand HTTP/1.1\r\n
   s>     Accept-Encoding: identity\r\n
   s>     user-agent: test\r\n
   s>     host: $LOCALIP:$HGPORT\r\n (glob)
   s>     \r\n
   s> makefile('rb', None)
   s>     HTTP/1.1 405 Method Not Allowed\r\n
   s>     Server: testing stub value\r\n
   s>     Date: $HTTP_DATE$\r\n
   s>     Allow: POST\r\n
   s>     Content-Length: 30\r\n
   s>     \r\n
   s>     commands require POST requests
 
 SSL required by default
 
   $ send << EOF
   > httprequest POST api/$HTTPV2/rw/customreadonly
   >     user-agent: test
   > EOF
   using raw connection to peer
   s>     POST /api/exp-http-v2-0001/rw/customreadonly HTTP/1.1\r\n
   s>     Accept-Encoding: identity\r\n
   s>     user-agent: test\r\n
   s>     host: $LOCALIP:$HGPORT\r\n (glob)
   s>     \r\n
   s> makefile('rb', None)
   s>     HTTP/1.1 403 ssl required\r\n
   s>     Server: testing stub value\r\n
   s>     Date: $HTTP_DATE$\r\n
   s>     Content-Length: 17\r\n
   s>     \r\n
   s>     permission denied
 
 Restart server to allow non-ssl read-write operations
 
   $ killdaemons.py
   $ cat > server/.hg/hgrc << EOF
   > [experimental]
   > web.apiserver = true
   > web.api.http-v2 = true
   > [web]
   > push_ssl = false
   > allow-push = *
   > EOF
 
   $ hg -R server serve -p $HGPORT -d --pid-file hg.pid -E error.log
   $ cat hg.pid > $DAEMON_PIDS
 
 Authorized request for valid read-write command works
 
   $ send << EOF
   > httprequest POST api/$HTTPV2/rw/customreadonly
   >     user-agent: test
   >     accept: $MEDIATYPE
   >     content-type: $MEDIATYPE
   >     frame 1 command-name eos customreadonly
   > EOF
   using raw connection to peer
   s>     POST /api/exp-http-v2-0001/rw/customreadonly HTTP/1.1\r\n
   s>     Accept-Encoding: identity\r\n
   s>     accept: application/mercurial-exp-framing-0002\r\n
   s>     content-type: application/mercurial-exp-framing-0002\r\n
   s>     user-agent: test\r\n
   s>     content-length: 20\r\n
   s>     host: $LOCALIP:$HGPORT\r\n (glob)
   s>     \r\n
   s>     \x0e\x00\x00\x01\x00\x11customreadonly
   s> makefile('rb', None)
   s>     HTTP/1.1 200 OK\r\n
   s>     Server: testing stub value\r\n
   s>     Date: $HTTP_DATE$\r\n
   s>     Content-Type: application/mercurial-exp-framing-0002\r\n
   s>     Transfer-Encoding: chunked\r\n
   s>     \r\n
   s>     23\r\n
   s>     \x1d\x00\x00\x01\x00Bcustomreadonly bytes response
   s>     \r\n
   s>     0\r\n
   s>     \r\n
 
 Authorized request for unknown command is rejected
 
   $ send << EOF
   > httprequest POST api/$HTTPV2/rw/badcommand
   >     user-agent: test
   >     accept: $MEDIATYPE
   > EOF
   using raw connection to peer
   s>     POST /api/exp-http-v2-0001/rw/badcommand HTTP/1.1\r\n
   s>     Accept-Encoding: identity\r\n
   s>     accept: application/mercurial-exp-framing-0002\r\n
   s>     user-agent: test\r\n
   s>     host: $LOCALIP:$HGPORT\r\n (glob)
   s>     \r\n
   s> makefile('rb', None)
   s>     HTTP/1.1 404 Not Found\r\n
   s>     Server: testing stub value\r\n
   s>     Date: $HTTP_DATE$\r\n
   s>     Content-Type: text/plain\r\n
   s>     Content-Length: 42\r\n
   s>     \r\n
   s>     unknown wire protocol command: badcommand\n
 
 debugreflect isn't enabled by default
 
   $ send << EOF
   > httprequest POST api/$HTTPV2/ro/debugreflect
   >     user-agent: test
   > EOF
   using raw connection to peer
   s>     POST /api/exp-http-v2-0001/ro/debugreflect HTTP/1.1\r\n
   s>     Accept-Encoding: identity\r\n
   s>     user-agent: test\r\n
   s>     host: $LOCALIP:$HGPORT\r\n (glob)
   s>     \r\n
   s> makefile('rb', None)
   s>     HTTP/1.1 404 Not Found\r\n
   s>     Server: testing stub value\r\n
   s>     Date: $HTTP_DATE$\r\n
   s>     Content-Type: text/plain\r\n
   s>     Content-Length: 34\r\n
   s>     \r\n
   s>     debugreflect service not available
 
 Restart server to get debugreflect endpoint
 
   $ killdaemons.py
   $ cat > server/.hg/hgrc << EOF
   > [experimental]
   > web.apiserver = true
   > web.api.debugreflect = true
   > web.api.http-v2 = true
   > [web]
   > push_ssl = false
   > allow-push = *
   > EOF
 
   $ hg -R server serve -p $HGPORT -d --pid-file hg.pid -E error.log
   $ cat hg.pid > $DAEMON_PIDS
 
 Command frames can be reflected via debugreflect
 
   $ send << EOF
   > httprequest POST api/$HTTPV2/ro/debugreflect
   >     accept: $MEDIATYPE
   >     content-type: $MEDIATYPE
   >     user-agent: test
   >     frame 1 command-name have-args command1
   >     frame 1 command-argument 0 \x03\x00\x04\x00fooval1
   >     frame 1 command-argument eoa \x04\x00\x03\x00bar1val
   > EOF
   using raw connection to peer
   s>     POST /api/exp-http-v2-0001/ro/debugreflect HTTP/1.1\r\n
   s>     Accept-Encoding: identity\r\n
   s>     accept: application/mercurial-exp-framing-0002\r\n
   s>     content-type: application/mercurial-exp-framing-0002\r\n
   s>     user-agent: test\r\n
   s>     content-length: 48\r\n
   s>     host: $LOCALIP:$HGPORT\r\n (glob)
   s>     \r\n
   s>     \x08\x00\x00\x01\x00\x12command1\x0b\x00\x00\x01\x00 \x03\x00\x04\x00fooval1\x0b\x00\x00\x01\x00"\x04\x00\x03\x00bar1val
   s> makefile('rb', None)
   s>     HTTP/1.1 200 OK\r\n
   s>     Server: testing stub value\r\n
   s>     Date: $HTTP_DATE$\r\n
   s>     Content-Type: text/plain\r\n
   s>     Content-Length: 322\r\n
   s>     \r\n
   s>     received: 1 2 1 command1\n
   s>     ["wantframe", {"state": "command-receiving"}]\n
   s>     received: 2 0 1 \x03\x00\x04\x00fooval1\n
   s>     ["wantframe", {"state": "command-receiving"}]\n
   s>     received: 2 2 1 \x04\x00\x03\x00bar1val\n
   s>     ["runcommand", {"args": {"bar1": "val", "foo": "val1"}, "command": "command1", "data": null, "requestid": 1}]\n
   s>     received: <no frame>\n
   s>     {"action": "noop"}
 
+Multiple requests to regular command URL are not allowed
+
+  $ send << EOF
+  > httprequest POST api/$HTTPV2/ro/customreadonly
+  >     accept: $MEDIATYPE
+  >     content-type: $MEDIATYPE
+  >     user-agent: test
+  >     frame 1 command-name eos customreadonly
+  >     frame 3 command-name eos customreadonly
+  > EOF
+  using raw connection to peer
+  s>     POST /api/exp-http-v2-0001/ro/customreadonly HTTP/1.1\r\n
+  s>     Accept-Encoding: identity\r\n
+  s>     accept: application/mercurial-exp-framing-0002\r\n
+  s>     content-type: application/mercurial-exp-framing-0002\r\n
+  s>     user-agent: test\r\n
+  s>     content-length: 40\r\n
+  s>     host: $LOCALIP:$HGPORT\r\n (glob)
+  s>     \r\n
+  s>     \x0e\x00\x00\x01\x00\x11customreadonly\x0e\x00\x00\x03\x00\x11customreadonly
+  s> makefile('rb', None)
+  s>     HTTP/1.1 200 OK\r\n
+  s>     Server: testing stub value\r\n
+  s>     Date: $HTTP_DATE$\r\n
+  s>     Content-Type: text/plain\r\n
+  s>     Content-Length: 46\r\n
+  s>     \r\n
+  s>     multiple commands cannot be issued to this URL
+
+Multiple requests to "multirequest" URL are allowed
+
+  $ send << EOF
+  > httprequest POST api/$HTTPV2/ro/multirequest
+  >     accept: $MEDIATYPE
+  >     content-type: $MEDIATYPE
+  >     user-agent: test
+  >     frame 1 command-name eos customreadonly
+  >     frame 3 command-name eos customreadonly
+  > EOF
+  using raw connection to peer
+  s>     POST /api/exp-http-v2-0001/ro/multirequest HTTP/1.1\r\n
+  s>     Accept-Encoding: identity\r\n
+  s>     accept: application/mercurial-exp-framing-0002\r\n
+  s>     content-type: application/mercurial-exp-framing-0002\r\n
+  s>     user-agent: test\r\n
+  s>     *\r\n (glob)
+  s>     host: $LOCALIP:$HGPORT\r\n (glob)
+  s>     \r\n
+  s>     \x0e\x00\x00\x01\x00\x11customreadonly\x0e\x00\x00\x03\x00\x11customreadonly
+  s> makefile('rb', None)
+  s>     HTTP/1.1 200 OK\r\n
+  s>     Server: testing stub value\r\n
+  s>     Date: $HTTP_DATE$\r\n
+  s>     Content-Type: application/mercurial-exp-framing-0002\r\n
+  s>     Transfer-Encoding: chunked\r\n
+  s>     \r\n
+  s>     *\r\n (glob)
+  s>     \x1d\x00\x00\x01\x00Bcustomreadonly bytes response
+  s>     \r\n
+  s>     23\r\n
+  s>     \x1d\x00\x00\x03\x00Bcustomreadonly bytes response
+  s>     \r\n
+  s>     0\r\n
+  s>     \r\n
+
+Interleaved requests to "multirequest" are processed
+
+  $ send << EOF
+  > httprequest POST api/$HTTPV2/ro/multirequest
+  >     accept: $MEDIATYPE
+  >     content-type: $MEDIATYPE
+  >     user-agent: test
+  >     frame 1 command-name have-args listkeys
+  >     frame 3 command-name have-args listkeys
+  >     frame 3 command-argument eoa \x09\x00\x09\x00namespacebookmarks
+  >     frame 1 command-argument eoa \x09\x00\x0a\x00namespacenamespaces
+  > EOF
+  using raw connection to peer
+  s>     POST /api/exp-http-v2-0001/ro/multirequest HTTP/1.1\r\n
+  s>     Accept-Encoding: identity\r\n
+  s>     accept: application/mercurial-exp-framing-0002\r\n
+  s>     content-type: application/mercurial-exp-framing-0002\r\n
+  s>     user-agent: test\r\n
+  s>     content-length: 85\r\n
+  s>     host: $LOCALIP:$HGPORT\r\n (glob)
+  s>     \r\n
+  s>     \x08\x00\x00\x01\x00\x12listkeys\x08\x00\x00\x03\x00\x12listkeys\x16\x00\x00\x03\x00"	\x00	\x00namespacebookmarks\x17\x00\x00\x01\x00"	\x00\n
+  s>     \x00namespacenamespaces
+  s> makefile('rb', None)
+  s>     HTTP/1.1 200 OK\r\n
+  s>     Server: testing stub value\r\n
+  s>     Date: $HTTP_DATE$\r\n
+  s>     Content-Type: application/mercurial-exp-framing-0002\r\n
+  s>     Transfer-Encoding: chunked\r\n
+  s>     \r\n
+  s>     6\r\n
+  s>     \x00\x00\x00\x03\x00B
+  s>     \r\n
+  s>     24\r\n
+  s>     \x1e\x00\x00\x01\x00Bbookmarks	\n
+  s>     namespaces	\n
+  s>     phases	
+  s>     \r\n
+  s>     0\r\n
+  s>     \r\n
+
+Restart server to disable read-write access
+
+  $ killdaemons.py
+  $ cat > server/.hg/hgrc << EOF
+  > [experimental]
+  > web.apiserver = true
+  > web.api.debugreflect = true
+  > web.api.http-v2 = true
+  > [web]
+  > push_ssl = false
+  > EOF
+
+  $ hg -R server serve -p $HGPORT -d --pid-file hg.pid -E error.log
+  $ cat hg.pid > $DAEMON_PIDS
+
+Attempting to run a read-write command via multirequest on read-only URL is not allowed
+
+  $ send << EOF
+  > httprequest POST api/$HTTPV2/ro/multirequest
+  >     accept: $MEDIATYPE
+  >     content-type: $MEDIATYPE
+  >     user-agent: test
+  >     frame 1 command-name eos unbundle
+  > EOF
+  using raw connection to peer
+  s>     POST /api/exp-http-v2-0001/ro/multirequest HTTP/1.1\r\n
+  s>     Accept-Encoding: identity\r\n
+  s>     accept: application/mercurial-exp-framing-0002\r\n
+  s>     content-type: application/mercurial-exp-framing-0002\r\n
+  s>     user-agent: test\r\n
+  s>     content-length: 14\r\n
+  s>     host: $LOCALIP:$HGPORT\r\n (glob)
+  s>     \r\n
+  s>     \x08\x00\x00\x01\x00\x11unbundle
+  s> makefile('rb', None)
+  s>     HTTP/1.1 403 Forbidden\r\n
+  s>     Server: testing stub value\r\n
+  s>     Date: $HTTP_DATE$\r\n
+  s>     Content-Type: text/plain\r\n
+  s>     Content-Length: 53\r\n
+  s>     \r\n
+  s>     insufficient permissions to execute command: unbundle
+
   $ cat error.log