Authentication error or maybe it isn't? - no user/password was provided

[Maxim Dounin]

Hello!

On Sun, Oct 20, 2013 at 04:17:34PM -0400, dalmolin wrote:

> I have set up an Nginx as a front end to manage secure connection and
> authorization for the Radicale calendar server which I use to synch my
> Lightning calendar on my desktop, laptop and Android phone (it uses the
> Caldav Synch app). It all works fine after a long and steep learning curve
> for me at least. One strange thing I have noticed is that I keep getting an
> error in the Nginx error log for the Android device, here are the
> abbreviated logs from Nginx's access.log and error.log:
> 
> access.log entries:
> 199.7.156.144 - - [20/Oct/2013:15:38:49 -0400] "OPTIONS
> /USERID/testcalhttps/ HTTP/1.1" 401 194 "-" "CalDAV-Sync (Android) (like
> iOS/5.0.1 (9A405) dataaccessd/1.0) gzip" "-"

[...]

> error.log entries:
> 2013/10/20 15:38:49 [error] 6797#0: *241 no user/password was provided for
> basic authentication, client: 199.1.1.1, server: , request: "OPTIONS
> /USERID/testcalhttps/ HTTP/1.1", host: "mysserver.com:1905"
> 
> The userid and password were correctly entered during setup of the calendar
> on the client and as I said it all works fine... I can add, delete, modify
> calendar entries and synch across all my devices. But I keep getting this
> pesky error when using my phone. 
> 
> I noticed that in the access.log the first access corresponds to the error
> message in the error log.... and then there are four more access messages
> with my USERID appended to the IP address. So it looks like the
> userid/password are processed after the first request somehow. Also, it may
> be helpful to know that the phone is connecting to Nginx via the internet
> and portforwarding via my router to the server. Might this error message
> simply be the result of the way I am accessing the server... as I don't get
> the same error when I access the server via the LAN and my laptop.

It looks like your client doesn't provide auth credentials on 
first request, but does so on subsequent ones after a 401 
response.  It's likely coded to work this way.

-- 
Maxim Dounin
http://nginx.org/en/donation.html