[PATCH] httprepo: use caps instead of between for compat check

Peter Arrenbrecht peter.arrenbrecht at gmail.com
Sun Mar 13 04:41:01 CDT 2011


On Sunday, March 13, 2011, Augie Fackler <durin42 at gmail.com> wrote:
> On Mar 13, 2011, at 1:00 AM, Peter Arrenbrecht wrote:
>>
>> On Sat, Mar 12, 2011 at 9:52 PM, Augie Fackler <durin42 at gmail.com> wrote:
>>> On Mar 12, 2011, at 1:22 PM, Benoit Boissinot wrote:
>>>>
>>>> On Sat, Mar 12, 2011 at 6:30 PM, Peter Arrenbrecht
>>>> <peter.arrenbrecht at gmail.com> wrote:
>>>>> # HG changeset patch
>>>>> # User Peter Arrenbrecht <peter.arrenbrecht at gmail.com>
>>>>> # Date 1299950942 -3600
>>>>> httprepo: use caps instead of between for compat check
>>>>>
>>>>> We usually query the capabilities at some point anyway so this way the first roundtrip
>>>>> actually does useful work.
>>>>
>>>> Queued, thanks!
>>>
>>> What happens when the server responds with garbage that isn't a valid capabilities list? Do we abort with some silly unsupported capability? What would happen if we tried talking to a newer server and it required a capability we lack locally?
>>
>> Maybe I'm missing something, but I don't think we would see anything
>> different than today, since the capabilities are practically always
>> requested at some point anyway. Even today, if the server responds
>> with something silly, we would get a failure (because it would raise
>> something other than RepoError).
>>
>> The only problem I see would be if a static http server were to send
>> garbage for the caps check, which it doesn't.
>> -parren
>
> Ah, I missed a key point: capabilities come back with a known content-type, which means it *is* a safe way to sniff for repo existence on modern servers.
>
> I'm convinced it's safe after some cURL use, might send a doc patch to add some comments for future viewers if that seems desirable (it's nonobvious at first reading why it's acceptable to trust _fetchcaps() to raise RepoError IMO, but I'm also very tired at the moment...)

I'm always for better docs. ;)
-parren


More information about the Mercurial-devel mailing list