> On Apr 17, 2018, at 7:40 AM, Yuya Nishihara <y...@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 <y...@tcha.org> wrote: >>>> >>>> On Sun, 15 Apr 2018 19:41:32 -0400, Matt Harbison wrote: >>>> # HG changeset patch >>>> # User Matt Harbison <matt_harbi...@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. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
