Question about No 'Authorization: Digest' header found.

[wjgilmore]

Hi,

Great project. We have everything up and running great, and are able to load/sync contacts no problem using multiple devices. However, I remain bothered by one lingering issue. Our Apache logs are littered with the following exception:

No 'Authorization: Digest' header found. Either the client didn't send one, 
or the server is mis-configured

I understand the nature of the message, however ultimately Apache (and the constituent Sabre authentication classes) is in fact authenticating the user because everything is working fine. These exceptions are thrown when connecting using both Android and iOS, so I don't think it is a client problem.

Any ideas why we're getting these despite successful authentication?

Thanks a million, Jason

[Frzk]

I guess it's OK. When the client isn't authenticated (yet), the server returns a response whose header contains a HTTP 401 Not Authorized status[ and a WWW-Authenticate field. That's what produces the log entries you see.

[wjgilmore]

Isn't the client authenticating with every single request? I'm under the impression the client, as part of the request process, sends the request (with username/password), and the server responds accordingly.

Or are you saying the clients starts off with an unauthenticated request attempt (meaning no Digest header), the server challenges, thus producing the error log line item, and the client subsquently responds with the appropriate header? If so, then I understand why this is happening, although it sure does result in the production of huge error logs.

[Frzk]

Well, yes, the first time, the client starts off with an unauthenticated request (because the resource might be accessible for everyone, or because the client doesn't know what the server is expecting for authentication).

The server replies with a 401, so that the client can re-send the request with the appropriate authentication headers.

Once successfully authenticated, the client should cache the authentication fields and send them along with the next requests. So the server shouldn't produce 401 (and error logs) for the next requests.

[wjgilmore]

Yes this is pretty much what I figured was supposed to happen, however both devices (Android and iOS) seem to be making effectively two requests for each typical request (one unauthenticated, which fails), and a second with the digest header, which passes. Why this is happening I haven't the faintest idea, but it's been going on for months. Apache is a plain vanilla configuration (with mod_digest installed of course).

As for clients, we're using CardDAV-sync free on Android and a regular old configuration profile on iOS.

Anyway thank you for the input, if I uncover anything in the coming days I'll be sure to report back.

[evert]

I'm reopening this. I've noticed this issue a lot too, even from clients that I would otherwise they would be 'better than that'. It might be worth doing another investigation to see if it's actually us who are in the wrong. I hope so, because it would indeed make everything faster.

As an aside:

with mod_digest installed of course

This made me laugh because you don't need it. The digest implementation is in sabre/http, we don't use apache's.

[wjgilmore]

LOL sorry about that @evert re mod_digest I am apparently clueless. We're seeing this behavior on both the native iPhone 5S (iOS 9.2) address book and on Android using the CardDAV-sync free app. For instance here is an example log snippet hailing from the iPhone:

"OPTIONS /principals/company/ HTTP/1.1" 401 356
"OPTIONS /principals/company/ HTTP/1.1" 200 -
"PROPFIND /principals/company/ HTTP/1.1" 401    
"PROPFIND /principals/company HTTP/1.1" 207     
"PROPFIND /addressbooks/company/ HTTP/1.1" 401  
"PROPFIND /addressbooks/company/ HTTP/1.1" 207  
"REPORT /addressbooks/company/personal/ 207 719 
"REPORT /addressbooks/company/personal/ 207 13081
"REPORT /addressbooks/company/global/ 207 1979

Pretty much every request/response sequence is associated with a failed authentication followed by a successful one. We've been seeing this behavior for a few months now.

[evert]

Yea I've personally seen this for almost 7 years. Hopefully there's something that can be done. It's worth a fresh look =)