[PATCH] httprepo: long arguments support (issue2126)

[Peter Arrenbrecht]

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