Hi,

I'm using curl to do some testing of a web application that uses Kerberos
authentication. It seems that when I use the --negotiate option, curl
initially sends a request with no credentials, and then when it gets a 401,
it sends another request, this time with the Kerberos credentials. This is
all a normal part of the HTTP Negotiate protocol.

The problem is, it only does this second request with the credentials if
the server keeps the same connection open. The initial request includes a
"Connection: keep-alive" header, but I'm using Django on the server side,
and it can't support that option. My server application ignores the
keep-alive header, but still conforms to the HTTP Negotiate protocol. But
curl just stops once the connection is closed.

Why doesn't curl fall back to just using a new connection for the second
request ,if the server doesn't honour the keep-alive request? I thought
that the keep-alive header is just a performance optimization.

Part of the reason I ask is that although I think this is a mistake in
curl, I've noticed that other clients have the same problem (e.g. Firefox).
Ultimately having it fixed in curl alone is probably not going to solve my
problem, but I'm wondering if I'm missing something - is there some reason
that it has to work this way? The RFC that defines this protocol doesn't
say anything about re-using the same connection (
https://tools.ietf.org/html/rfc4559#page-4). It just says the 401 should be
followed by another request with the credentials.

Can anyone explain why it's done this way?

Thanks for reading. If it's relevant, here's my "curl --version" info:

curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.19.1 Basic ECC
zlib/1.2.7 libidn/1.28 libssh2/1.4.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3
pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz

-John

-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-02-02