[PATCH] httprepo: long arguments support (issue2126)

[Steven Brown]

On 29 March 2011 20:40, Peter Arrenbrecht <peter.arrenbrecht at gmail.com> wrote:
> On Tue, Mar 29, 2011 at 1:47 PM, Steven Brown <stevengbrown at gmail.com> wrote:
>> On 29 March 2011 01:59, Augie Fackler <durin42 at gmail.com> wrote:
>>> On Mon, Mar 28, 2011 at 12:58 PM, Laurens Holst <laurens.nospam at grauw.nl> wrote:
>>>> Op 28-3-2011 19:38, Augie Fackler schreef:
>>>>>
>>>>> On Mon, Mar 28, 2011 at 12:13 PM, Laurens Holst<laurens.nospam at grauw.nl>
>>>>>  wrote:
>>>>>>
>>>>>> Good point :).
>>>>>>
>>>>>> In that case I would suggest to just add custom headers instead of
>>>>>> (abusing)
>>>>>> cookies for this...
>>>>>>
>>>>>> X-Mercurial-Changesets: 7248fd2710572839e3459d3d374eb9565edebbab,
>>>>>> b12142c8ba342fffac9280a528194fbec77c74fd,
>>>>>> 438fe4ee31b4531ee4a7f068d1affa402b1a3eb9
>>>>>>
>>>>>> Servers shouldn’t have a problem with that, and normal header length
>>>>>> rules
>>>>>> should apply. You should also be able to add multiple headers of the same
>>>>>> name in case of comma separated values[1]. (To be a little briefer you
>>>>>> could
>>>>>> also name the header X-Hg-Changeset.)
>>>>>
>>>>> +1, I've suggested this in the past and it sounds reasonable. We
>>>>> should also make sure that any response to a request that used headers
>>>>> sets appropriate cache-control headers to avoid potential GET caching
>>>>> issues.
>>>>
>>>> Actually I think you should use the Vary header for that:
>>>>
>>>> Vary: X-Hg-Changesets
>>>>
>>>> Should do the trick.
>>>
>>> Ah yes. Always forget about that one.
>>>
>>>>
>>>> ~Laurens
>>>>
>>>> --
>>>> ~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
>>>> Laurens Holst, developer, Utrecht, the Netherlands
>>>> Website: www.grauw.nl. Backbase employee; www.backbase.com
>>>>
>>>>
>>>>
>>>
>>
>> I don't understand why we want caching. In general, Mercurial could return
>> a different response for the same request. For example:
>> 1) Client requests heads.
>> 2) New head is created on the server.
>> 3) Client requests heads again.
>>
>> What am I missing?
>
> If I understood this correctly, you could have a caching proxy in
> front of hgweb. If this proxy is the only way to reach the repos
> there, then the proxy can use the fact that only POST requests can
> mutate the repo state. So identical GETs w/o intervening POSTs can be
> served from a cache. The Vary: header tells the cache to add the
> contents of the header fields listed in the value of Vary: to its
> cache lookup key instead of using just the URL.
>
> -parren
>

I get it. Thanks.