[PATCH] httprepo: long arguments support (issue2126)

Steven Brown stevengbrown at gmail.com
Sat Apr 30 08:25:47 CDT 2011


On 30 April 2011 20:54, Matt Mackall <mpm at selenic.com> wrote:
> On Sat, 2011-04-30 at 20:35 +0800, Steven Brown wrote:
>> # HG changeset patch
>> # User Steven Brown <StevenGBrown at gmail.com>
>> # Date 1304163787 -28800
>> # Node ID 9ae060e1ef6955a05965dde63a4782a78065b6cf
>> # Parent  139fb11210bb4fc1206d69bbe56b3a15b934bc11
>> httprepo: long arguments support (issue2126)
>>
>> Send the command arguments in the HTTP headers. The command is still part
>> of the URL. If the server does not have the 'httpheader' capability, the
>> client will send the command arguments in the URL as it did previously.
>>
>> Web servers typically allow more data to be placed within the headers than
>> in the URL, so this approach will:
>> - Avoid HTTP errors due to using a URL that is too large.
>> - Allow Mercurial to implement a more efficient wire protocol.
>>
>> An alternate approach is to send the arguments as part of the request body.
>> This approach has been rejected because it requires the use of POST
>> requests, so it would break any existing configuration that relies on the
>> request type for authentication or caching.
>>
>> Extensibility:
>> - The header size is provided by the server, which makes it possible to
>>   introduce an hgrc setting for it.
>> - The client ignores the capability value after the first comma, which
>>   allows more information to be included in the future.
>
> I don't know if this format is compact enough. While IIS has a limit
> based on total request size, Apache has a fairly small limit on number
> of header lines (~100 by default), though it allows those lines to be
> quite long (~8k by default).
>
> In your approach, we're using one arg per header, which means we have a
> limited number of args, with a limited size each. We can't have one 50k
> arg and we can't have 500 100-byte args.

It is using one or more headers per argument, so it would be possible
to send a 50k argument.

> Instead, we probably want to build one big request string and then break
> it across a bunch of large headers. Then the receive can combine them
> all and unpack.

I think the efficiency difference would be minor. A typical command
has no more than 2 or 3 arguments.

However, your approach will probably result in simpler code, so I'll
give it a go.


More information about the Mercurial-devel mailing list