Re: [ietf-http-auth] HTTP Mutual-auth proposal status / HTTP AUTH meet-up in Anaheim?

Sorry for the delay in the response, I finally managed to do tests on
an iPhone and Windows Mobile phone only today.

On Wed, Jan 6, 2010 at 8:45 AM, Yutaka OIWA wrote:
>>>> Why introduce the Optional-WWW-Authenticate? why not just use a
>>>> WWW-Authenticate header in non-401 responses?
>>>> See
> Can I ask the opposite question:
> why do you want to overload existing WWW-Authenticate header for
> optional authentication?
> I think the separate header is better because (1) the meaning differs
> (users MAY be authorized <-> users MUST either be authorized or give
> up) from the existing header,

The "MUST" comes from the 401/407 status code, note from the
WWW-Authenticate response header field.

> and (2) it is semantically safe with
> existing implementations.

I have tested: IE 6/7/8, Firefox 3.0/3.5/3.6, Opera 9.64/10.10/10.50,
Safari 4.0.4, Chrome 3.0/4.0 (stable/beta/dev), all on Windows XP; IE8
on Vista; Lynx, Links and w3m (recent versions) on Linux, iPhone
3.1.2, Opera Mobile 9.5 on Windows Mobile 6.1, Pocket IE on WinMob
6.1, Opera Mini 4 and Opera Mini 5 beta (on J2ME phones), NetFront 3.4
(Samsung Player Style built-in browser) and SEMC (Sony Ericsson K750i
built-in browser); and *all* of them ignore a WWW-Authenticate header
in a 200 response (tested with my proposed Cookie scheme, and with
Basic scheme):

> I am really counting on your survey on many existing implementations,
> but semantical safety is always better than experimental safety, isn't
> it?

And I do believe that WWW-Authenticate on a non-401/407 response is
"semantically safe".

> P.S.
> I do not know whether it is critical, but there is at least one mail
> referring to a existing conflicting use of the WWW-Authenticate header
> (to carry authentication information on final successful response)
> in a 200 response:
> My proposal and Digest authentication uses a separate Authentication-Info:
> header for this purpose.

It's clearly not critical as, as mentioned in the mail, it only
appears after an initial challenge in a 401 response (client sends a
request, server responds with 401+NTLM, client and server exchange
several requests/401-responses to mutually authenticate each other,
and in the end the server sends the 200 --or whatever-- response,
along with a final WWW-Authenticate)

> In the same thread there mentioned a browser responding on WWW-authenticate
> header in a 200 response:

I tested a recent version of w3m and it didn't behave that way.

Thomas Broyer

Received on Thursday, 21 January 2010 19:38:09 UTC