On Sat, 11 Jul 2020, Jakob Reschke wrote:

> Hi all,
>
> Am Sa., 11. Juli 2020 um 13:53 Uhr schrieb Eric Gade <eric.gade at gmail.com>:
>>
>>> Could you please inspect whether the `response request` actually
>>> contains authentication headers? I have seen in the past that
>>> sometimes the WebClient does not send them when it should.
>>
>>
>> It looks to me like the WebClient's response request (the original request sent I assume) headers *don't* have any Auth information: ` 'an OrderedCollection(''Content-Type''->''application/x-git-receive-pack-request'' ''Content-Length''->5343 ''User-Agent''->''git/2.0.5'' ''Host''->''github.com'')'`
>>
>
> To me these missing auth headers look like a WebClient bug because the
> GitSmartHTTPProtocol class (comes with the Git Browser) clearly
> supplies the credentials to the client (see
> discoverReferencesForService:, requestCredentials, applyCredentials)
> and uses the same WebClient instance for the whole push operation,
> which entails two requests (discover references is the first, invoke
> receive pack is the second).
>
> If the misbehavior triggers, the second request is usually the one
> that is missing the auth headers. I have already seen this
> sporadically myself, but not lately. Repeating the request (by
> restarting the method) usually resolves the problem.
>
> Does anyone have a hint? It is possible that I have wrong expectations
> about the WebClient interface and how it remembers the credentials...

Perhaps this part of WebClient >> #sendRequest:contentBlock: is 
responsible:

 	"Flush previous authState.
 	XXXX: Fixme. authState must be preserved for pre-authentication of requests."
 	self flushAuthState.

#flushAuthState removes the passed credentials.

Also, any kind of redirect will remove the credentials.


Levente

>
> Kind regards,
> Jakob