[PATCH] lfs: add the 'Authorization' property to the Batch API response, if present

Matt Harbison mharbison72 at gmail.com
Tue Apr 17 07:57:54 EDT 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