Hi all

> On 01.10.2018, at 23:45, tim Rowledge <tim at rowledge.org> wrote:
> 
> Yay! Winner!
> 
>> On 2018-10-01, at 2:30 PM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>> 
>> On Mon, 1 Oct 2018, tim Rowledge wrote:
>> 
>>> 
>>> I suspect I can make up a way to do a more direct use-auth-first-time approach that might be better when you know it has to have it. After my frog pills...
>> 
>> Yes you can. You just have to add the Authorization header yourself. Adding basic auth manually to the example in help would look something like this:
>> 
>> 	| client username password response |
>> 	client := WebClient new.
>> 	username := 'Tim'.
>> 	password := 'secret'.
>> 	response := client httpGet: 'http://www.squeak.org/protected' do: [ :request |
>> 		request headerAt: 'Authorization' put: 'Basic ', (username, ':', password) base64Encoded ].
>> 	response content. "Prefetch response body before closing the client."
>> 	client close. "Do not let WebClient instances leak external semaphores."
>> 	^response
> 
> I saw the httpGet:do: but hadn't a clue how to assemble the header bit. Thank you!

Just for completeness sake, If your server gives you a 401 but Not a WWW-Authenticat, they're doing it wrong:

	https://tools.ietf.org/html/rfc7235#section-4.1
	"A server generating a 401 (Unauthorized) response MUST send a
	 WWW-Authenticate header field containing at least one challenge"

On the other hand, the 401-before-Authenticat is the norm but not RFC required:

	https://tools.ietf.org/html/rfc7235#section-4.2
	"The "Authorization" header field allows a user agent to authenticate
	itself with an origin server -- usually, but not necessarily, after
	receiving a 401 (Unauthorized) response. "

However, proactively sending Authorization-headers is a grave security issue. It Should Not Be Done.

Hence, I think WebClient's variant is ok.

That being said, maybe we can introdue a proactive auth flag.

Best regards
	-Tobias