You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
gitproto: defer credential approval until response passes validation
Both credential-approval paths previously called CredentialHelper.Approve
as soon as the retried request returned 2xx — before RequestInfoRefs
validated the advertisement content-type and applied its size cap. A
misleading 2xx (e.g. a captive-portal HTML body) would persist the
credentials in the helper even though RequestInfoRefs still returned
an error.
Unify around the existing pendingHelperCreds slot:
- tryHelperRetry no longer calls Approve directly on a 2xx retry. It
sets c.Auth (so follow-ups on the same conn reuse the creds) and
records the creds as pending, leaving approval to the caller.
Rejection on 401/403/transport-error stays immediate — a definite
auth failure is unambiguous.
- resolvePendingHelperCreds gains a success bool. Approve only fires
when the operation actually succeeded (status 2xx *and* body
validation passed); Reject still fires on 401/403; everything else
leaves the creds pending and c.Auth in place.
- RequestInfoRefs now reads/validates first (httpError, content-type,
redirect, size cap — extracted into readInfoRefsResponse) and only
then settles helper state with success=(err==nil).
- PostRPCStreamBody settles with success=(httpError==nil), which is
the full success signal for the POST path.
Adds TestRequestInfoRefs_OnUnauthorizedRetry2xxBadContentTypeDoesNotApprove
to pin the new contract: a 2xx retry with a non-advertisement body must
error out and must NOT call Approve (or Reject — it isn't an auth
failure).
Addresses Cursor Bugbot review comment on PR #65: "Premature credential
helper approve".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments