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? > 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
