On Mon, Jun 30, 2025 at 06:29:46PM +0000, brian m. carlson wrote: > On 2025-06-30 at 15:09:06, Michal Suchánek wrote: > > On Mon, Jun 30, 2025 at 02:31:15PM +0000, brian m. carlson wrote: > > > It is in fact desirable because otherwise the user continues to attempt > > > to use the bad credentials and then can never again authenticate > > > successfully, since they are never again prompted for credentials. > > > > My proglem is that the credentials are actually valid, only the > > operation is not. The current behavior erases valid credentials. > > Then the server needs to return a 403 or 404 and not a 401. A 401 > prompts Git to expire credentials and a 403 or 404 does not. Only the > server knows whether the credentials are actually valid for some access > or not at all. > > RFC 9110 § 15.5.2 says this: > > The 401 (Unauthorized) status code indicates that the request has > not been applied because it lacks valid authentication credentials > for the target resource. > > and § 15.5.4 says this: > > The 403 (Forbidden) status code indicates that the server understood > the request but refuses to fulfill it. > […] > If authentication credentials were provided in the request, the > server considers them insufficient to grant access. The client > SHOULD NOT automatically repeat the request with the same > credentials. The client MAY repeat the request with new or different > credentials. > […] > An origin server that wishes to "hide" the current existence of a > forbidden target resource MAY instead respond with a status code of > 404 (Not Found). > > So the server is incorrect in returning a 401 in this case if the > credentials are actually valid for a different operation on the same > resource. Is there any way to see what the server is returning? As the repository uses SSL capturing the communication with a proxy would be challenging. Thanks Michal
