HTTP/1.1 Digest authentication

[Markus Mehlan]

Hi,

my device is a measurement device for internet services
(Ethernet/Voip/IPTV). The device requests the VOIP configuration
from the ACS.

My problem was, that the device has closed the read-socket after
each response from the ACS. So the "keep-alive" took no effect
and the ACS sent the FIN. BTW HTTP/1.1 uses "Connection: keep-alive"
by default.

I fixed that and now it works as expected.

Best greetings,
Markus

Am 28.05.2015 um 16:24 schrieb Zaid Abdulla:
> On Thu, May 28, 2015, at 04:54 PM, Markus Mehlan wrote:
>> Hi,
>>
>> when I use the HTTP Digest authentication for a ConnectionRequest with
>> HTTP/1.1 Header (./config/auth,json), the CPE must use the header
>> parameter "Connection: close" in the response, otherwise it doesn't
>> work. Why does Connection: keep-alive not work?
>> A Test with curl was successful.
>> curl -v --digest -u user:passsord
>> http://10.5.108.239:7777/651c50c244d715e78921a546532654b0
>
> I'm struggling with a related issue as we speak. It may very well be the
> exact same problem. Here's what I found:
>
> 1) The ACS sends connection request.
>
> 2) CPE replies with 401 and an authentication challenge and includes the
> header "Connection: Keep-Alive".
>
> 3) The ACS generates the authentication header based on the given
> challenge, and sends that using the already existing TCP connection.
>
> The issue I found is that the device will disconnect the TCP connection
> (by sending FIN) right after step 2. However, by the time the FIN packet
> is received the ACS has already attempted to send the follow up request
> (step 3) over the existing connection, and this results in a failure. By
> the looks of it, it looks like a CPE problem that it sends a keep-alive
> header and immedialty destroys the connection. This explains why it
> works when the CPE sends "Connection: close" (haven't tested this
> myself) as the ACS will be aware that the connection cannot be reused
> and will open a new one.
>
> A simple workaround is to wrap the following line in ap-functions.coffee
> in a setTimeout() function to delay the response a little so that the
> connection is already closed by the time the ACS send a follow up
> request:
>
>      callback(res.statusCode, authHeader)
>
> I'm thinking of a less hacky workaround to implement. Ideas are welcome.
>
> I've only had this problem with Tilgin devices. What is your device?
>
> Zaid
>