On Fri, 2014-05-09 at 13:46 +0200, Kamil Dudka wrote:
> On Friday 09 May 2014 13:25:21 Daniel Stenberg wrote:
> > On Fri, 9 May 2014, Kamil Dudka wrote:
> > > ... 'WWW-Authenticate: Negotiate' received from server
> >
> > Seems reasonable to me!
>
> Thanks for review! I have pushed the patch:
>
> https://github.com/bagder/curl/commit/ec5fde24

Hrm, I think I just broke this again. In retrospect, it wasn't the right
fix. We really do need to process WWW-Authenticate: Negotiate even when
we're in the GSS_AUTHSENT state.

However, if we're in the GSS_AUTHRECV state, that means we have already
*received* a 'WWW-Authenticate: Negotiate' header on *this* time round
the loop.... doesn't it?

So the code I just submitted is *almost* doing the right thing by
processing it only when the state us GSS_AUTHNONE or GSS_AUTHSENT.

It's just that it shouldn't necessarily be setting
data->state.authproblem when it sees the duplicate header; it should be
ignoring it. So do we just remove the 'else' clause at line 793 of
http.c?

There's also another, deeper problem with both this and the original
patch referenced above... it assumes that the first of the duplicate
headers is actually the one we want.

In this case there was an empty 'WWW-Authenticate: Negotiate\r\n' and
also another one with a token, and the one with the token came *first*
so that was fine.

But in the case where we get an empty header and *then* one with a
token, surely it'll still be the one with the token that we want to
process? So perhaps we actually want some kind of pre-processing to
happen rather than taking the first one we see?

Could we just *store* the token at this point, then do the work of
producing the result later in Curl_output_negotiate()? Or is that much
too hard because we also need to know at input time whether we're going
to *try* each auth method...?

-- 
dwmw2

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html