[PATCH] lfs: add the 'Authorization' property to the Batch API response, if present
Matt Harbison
mharbison72 at gmail.com
Tue Apr 17 11:57:54 UTC 2018
> On Apr 17, 2018, at 7:40 AM, Yuya Nishihara <yuya at tcha.org> wrote:
>
>> On Mon, 16 Apr 2018 08:22:13 -0400, Matt Harbison wrote:
>>
>>>> On Apr 16, 2018, at 7:58 AM, Yuya Nishihara <yuya at tcha.org> wrote:
>>>>
>>>> On Sun, 15 Apr 2018 19:41:32 -0400, Matt Harbison wrote:
>>>> # HG changeset patch
>>>> # User Matt Harbison <matt_harbison at yahoo.com>
>>>> # Date 1523027627 14400
>>>> # Fri Apr 06 11:13:47 2018 -0400
>>>> # Node ID 6d8c47590030244033d51c2d0b390d2ee6337dea
>>>> # Parent acd5a25c179269df689b8799aa7cbc52d5451251
>>>> lfs: add the 'Authorization' property to the Batch API response, if present
>>>>
>>>> The client copies all of these properties under 'header' to the HTTP Headers of
>>>> the subsequent GET or PUT request that it performs. That allows the Basic HTTP
>>>> authentication used to authorize the Batch API request to also authorize the
>>>> upload/download action.
>>>
>>> I'm not pretty sure, but I think it's up to the client to resend an
>>> Authorization header depending on the realm provided by the server. Doesn't
>>> the server request authentication for batch requests?
>>
>> It does request authentication for batch requests, but doesn’t for the transfer, which surprised me. Somewhere I think I read that the authentication request is also tied to the URI, which would explain why the client isn’t resending on its own.
>
> Queued, but can you investigate further why the server doesn't send 401
> response?
Will do. There’s more to look at in this area in general, and the lfs spec in this area is a bit vague, at least to me.
>> I wireshark traced git-lfs to a couple of different servers, and this seemed to be what it was doing. That gitbucket footnote shows it rolling its own authorization token that it expects on transfer, so I thought this was by design.
>
> Sending new token might make some sense, but echoing back the original
> Authorization header seems a bit weird.
More information about the Mercurial-devel
mailing list