Re: WWW-Authenticate / Proxy-Authenticate with 200 response

Without knowing much about SPEGNO, this seems like a use case for the Authentication-Info header (see RFC2617), at least conceptually. Right now it's specific to Digest, but it would be reasonable to talk about changing it to allow extensions, or to use a different header if that isn't workable.

Regards,


On 18/11/2010, at 11:06 AM, Adrien de Croy wrote:

> 
> Hi all
> 
> I've just been doing some research on this, since I've seen a case where SPNEGO is being used (for proxy auth actually which seems to contravene SPNEGO RFC 4559 S.6 para 3) resulting in a final chunk of auth protocol data lying around needing to go back to the client even though the auth was successful.
> 
> My initial thoughts were to drop this, since obviously one mustn't send a WWW-Authenticate or Proxy-Authenticate header in a 200 response.  Wrong.
> 
> The SPNEGO spec actually indicates it's intended to send such a header in a success response.
> 
> I'm just wondering while we're updating the specs for authentication, whether the prose around the WWW-Authenticate and Proxy-Authenticate headers should indicate it may also appear in responses other than 401/407 respectively.  At the moment it states the header MUST appear in a 401/407 but that's it.  It's not intuitive to expect to see one in another response.
> 
> Why anyone would use NTLM over SPNEGO over HTTP is beyond me though.  Makes a painful 3-request NTLM handshake seem like bliss compared to the extra steps involved and resulting SPNEGO agony.  Especially since the browser cannot know apriori if the server/proxy will require auth for any particular request/connection.  This is one of the problems of offloading this task to an underlying system (SSPI) that doesn't know what it's being layered over.
> 
> Regards
> 
> Adrien
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 6 December 2010 23:43:33 UTC