[PATCH] httprepo: long arguments support (issue2126)

[Peter Arrenbrecht]

On Mon, Mar 21, 2011 at 9:00 PM, Peter Arrenbrecht
<peter.arrenbrecht at gmail.com> wrote:
> On Mon, Mar 21, 2011 at 8:56 PM, Peter Arrenbrecht
> <peter.arrenbrecht at gmail.com> wrote:
>> On Mon, Mar 21, 2011 at 2:39 AM, Matt Mackall <mpm at selenic.com> wrote:
>>> On Mon, 2011-03-21 at 09:15 +0800, Steven Brown wrote:
>>>> On 20 March 2011 23:27, Matt Mackall <mpm at selenic.com> wrote:
>>>> > On Sun, 2011-03-20 at 18:10 +0800, Steven Brown wrote:
>>>> >> # HG changeset patch
>>>> >> # User Steven Brown <StevenGBrown at gmail.com>
>>>> >> # Date 1300614413 -28800
>>>> >> # Node ID dd1002a1476d86eace9724ef04b502b724fc0525
>>>> >> # Parent  48d606d7192b6f8f4fc8071fccdc5a83843ab2d3
>>>> >> httprepo: long arguments support (issue2126)
>>>> >>
>>>> >> Send the command arguments in the HTTP request body. The command is still part
>>>> >> of the URL. If the server does not have the 'longargs' capability, the client
>>>> >> will send the command arguments in the URL as it did previously.
>>>> >>
>>>> >> When sending both command arguments and additional data in the same request,
>>>> >> the client adds a 'datastart' field to the URL. The server uses this to
>>>> >> determine where the command arguments end and the additional data begins.
>>>> >
>>>> > One of the reasons we were focusing on stashing stuff in headers is that
>>>> > some folks might be relying on non-push requests being GETs in their web
>>>> > server access rules. I'm not sure if this is a real problem, though.
>>>> > Obviously, a POST approach is a lot cleaner.
>>>>
>>>> Ahh, I see. I didn't realise there were any advantages to using the headers.
>>>>
>>>> Perhaps long argument support should be off by default, with an option
>>>> in the server's hgrc to turn it on? Then at least Mercurial would
>>>> continue working after the upgrade in this case.
>>>
>>> Let's try to get more discussion on whether POST is acceptable and
>>> anyone is using POST filtering.
>>>
>>>> Potential issues with using the headers:
>>>> - Each web server would have a different header size, so it may be
>>>> necessary to provide this header size in the hgrc. Putting the
>>>> arguments in the body would require no configuration, except perhaps
>>>> the on/off flag mentioned above.
>>>
>>> I think we should be aiming for a one-size-fits-all-no-config solution.
>>
>> Seconded. Otherwise discovery will again have to try to work around
>> servers that don't support the necessary request sizes.
>
> Hmm. Actually it would probably not be too hard to make the new
> discovery adapt to limited servers, except for the number of heads
> problem, which also bites changegroup/getbundle (as Matt said). But I
> would still prefer an approach that is uniform across servers.

It would actually be very simple to make new the discovery adapt
dynamically to the supported URL length. All it does, after all, is
send samples to known(), which it could either just break up into
multiple roundtrips, or else reduce its sample size. The latter would
have the advantage that it would rebuild its view of known-common and
known-missing for every roundtrip, potentially making each roundtrip
discover more.
-parren