Hi David, > Gesendet: Donnerstag, 17. Juli 2014 um 11:41 Uhr > Von: "David Woodhouse" <dw...@infradead.org> > An: "Kamil Dudka" <kdu...@redhat.com> > Cc: curl-library@cool.haxx.se, "Daniel Stenberg" <dan...@haxx.se> > Betreff: Re: [PATCH] http: avoid auth failure on a duplicated header > > 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...?
Given a server sends a single response header: After my commit would have been merged, I wanted to rework that stuff anyway. As I have already layed out before, the enum 'state' is not well-designed. It needs to be tied to context state. The issue is that your server does not behave the way intended. That requires a custom fix in curl. The other issue with curl is that it performs preemptive auth which is a bug because the RFC say MAY. That requires an option --preemptive. Especially, not all acceptors are capable of processing preemptive auth. Michael ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
