This looks like an upstream issue, if it's not a Links config problem. I was testing Digest authentication with a servlet under JBoss that I've developed (though I suspect Apache could reproduce this as well, with some work; I'd have to try it). It turns out that Links is recognizing the WWW-Authenticate: Digest header in the 401 response and prompts the user for username and password -- but then turns around and sends an Authorization: Basic <base64-encoded> response. This is quite obviously wrong, though it's not a security concern as such, just a bug. (This is links-2.1_pre17.) Reproducible: Always Steps to Reproduce: 1. Configure Apache, JBOSS, or other such to enable Digest authentication. (I ran into this bug because I'm doing some custom code that works very well with Mozilla/Firefox -- and even with IE.) 2. 'emerge links' if necessary. 3. Turn on a sniffer. I use tcpdump but there are presumably others. 4. Try to access the website using Links and using Mozilla or Firefox. 5. Look at the dumped packets. Actual Results: Mozilla works fine; authentication proceeds and the response comes back. Links gets a 400 Bad Request error. The logs on the servlet side (in JBoss, at least) clearly show the bad header coming back. (For what it's worth, Lynx (another browser) is showing more or less correct behavior, if only because it can't understand Digest authentication so it basically gives up and shows the 401 response.) Expected Results: A good question. Ideally, Links would fully implement RFC2617, or at least enough to do the right thing by Apache. Either that, or it could spit out a message locally stating that "sorry, we don't do Digest Authentication", to warn the user. See http://www.ietf.org/rfc/rfc2616.txt and http://www.ietf.org/rfc/rfc2617.txt for the gory details. Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.20041102-r1, 2.6.10-gentoo-r6 i686) ================================================================= System uname: 2.6.10-gentoo-r6 i686 AMD Athlon(TM) XP 1600+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Apr 29 2005, 20:55:04)] distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r1, 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -mcpu=athlon-xp -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=athlon-xp -march=i686 -pipe" DISTDIR="/data/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" LANG="en_US.iso88591" MAKEOPTS="-j3" PKGDIR="/usr/portage_packages.aurigae" PORTAGE_TMPDIR="/data/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow X aalib acpi acpi4linux alsa apm arts avi berkdb bitmap-fonts cdr crypt cups curl eds emboss encode esd f77 fam flac foomaticdb fortran gd gdbm ggi gif gimpprint gnome gnomedb gpm gstreamer gtk gtk2 guile imagemagick imlib ipv6 jack java jpeg junit kde libg++ libwww mad mikmod mmx motif mozilla mp3 mpeg nas ncurses nls nptl ogg oggvorbis opengl oss pam pdflib perl png postgres ppds python qt quicktime readline sdl slang snmp spell ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts unicode vorbis xine xml2 xmms xv zlib video_cards_fglrx video_cards_radeon userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS, LINGUAS
Hi there, Thanks for bringing the bug up. Have you a) tested a hand-compiled version b) contacted upstream? This does look like an upstream problem, where they would be more apt to solve it quickly.
Please re-open if a handcompiled version yields a different result. Otherwise I am taking this is an upstream issue and should be reported to them.
A patch from upstream is in -r2 for testing.
