[PATCH] httprepo: long arguments support (issue2126)

[Peter Arrenbrecht]

On Mon, Mar 28, 2011 at 8:27 AM, Peter Arrenbrecht
<peter.arrenbrecht at gmail.com> wrote:
> On Mon, Mar 28, 2011 at 12:33 AM, Laurens Holst <laurens.nospam at grauw.nl> wrote:
>> Op 27-3-2011 14:35, Steven Brown schreef:
>>>
>>> Idea: We limit the query string length to 2048 bytes, and switch to a POST
>>> request if it is longer. This will allow long arguments to be used with
>>> Apache and IIS.
>>>
>>> (See the default maxQueryString at
>>>
>>> http://www.iis.net/ConfigReference/system.webServer/security/requestFiltering/requestLimits)
>>>
>>> If we get bug reports for more restrictive web servers, we can then
>>> further
>>> reduce the maximum query string size. Hopefully, by this time, most web
>>> servers will have the new configuration and will be unaffected.
>>
>> I think it’s better to just always use GET, and only use the POST
>> alternative when you get an HTTP 414 Request-URI Too Long[1] response. This
>> means you will have an additional request in those cases, but they shouldn’t
>> be common, and an extra request isn’t that big a deal (look how many
>> requests the average web page makes).
>>
>> I think this is a nicer approach than guessing and hard-coding a particular
>> maximum size. This way existing server setups won’t be impacted, as the
>> behaviour only changes for repositories that already have problems (which I
>> think is a small minority?), and for those it changes for the better.
>>
>> Note that the POST fallback does have the downside of possibly causing an
>> authentication prompt, and an extra round-trip. To avoid this you can
>> recommend users to change the server configuration to allow longer query
>> strings (you already found the relevant setting for IIS), or to clean up the
>> number of heads in the repository. As I argued in my other mail, I wouldn’t
>> recommend making authentication exceptions for certain POST queries, that’s
>> very risky.
>>
>> If someone can come up with a way to change the current protocol so that it
>> doesn’t create such long request URLs anymore, or to make it use multiple
>> GET queries instead of a POST if it receives a 214 error (maybe at the
>> expense of some efficiency), that would of course also be good. Because I
>> think resorting to POST for this is more of a workaround than a real fix.
>
> For the general case of getbundle() / changegroupsubset() this will
> likely be hardest because I don't see how you can avoid transmitting
> all of the common heads/bases in one go. Unless you're willing to add
> short-lived state to the server to build them up incrementally.
>
> One approach that uses only a fairly persistent form of shortlived
> state would be to add a function that requests the server's revlog

Ah, the convoluted rubbish I write at times. What I mean is it makes
use of server-side information that, while not strictly stable,
generally is so for most of the time. And that is the mapping of node
ids to revlog indices.
-parren

> indices for a couple of node ids. One could then send common and heads
> as revlog indices instead of node ids in getsubset(). This would, of
> course, break if the server's changelog were rearranged in the
> meantime (really not likely, I guess - maybe in case of server-side
> rollback or restore from backup?).
>
> Such a query for revlog indices might in fact become an option to
> known(), telling it to return actual indices instead of just 1 for
> known nodes.
>
> -parren
>
>>
>> ~Laurens
>>
>> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.15
>>
>> --
>> ~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
>> Laurens Holst, developer, Utrecht, the Netherlands
>> Website: www.grauw.nl. Backbase employee; www.backbase.com
>>
>>
>>
>