[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] TCP connection closed with Digest auth

From: Christian Grothoff
Subject: Re: [libmicrohttpd] TCP connection closed with Digest auth
Date: Wed, 8 Jan 2020 17:52:47 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

Hi Ahmed,

I think MHD is right to close the connection after returning the 401,
simply because due to the PUT + Expect: 100-continue we cannot be sure
if the client received the 401 *before* starting the upload, as clients
are expected to start the upload after a few 100ms in the _absence_ of a
response (i.e. in case the server doesn't support Expect: 100-continue).
So MHD doesn't know if what comes next is the PUT body *or* the next
HTTP request, and we refuse to guess.

That said, we probably SHOULD signal the HTTP client that we'll be
closing the connection (and MIGHT right now erroneously signal that we
would keep it alive). The attached patch adds the "Connection: close" to
the 401 reply.

Could you please try your logic with the patch and report if it improves
the compatibility with the clients?



On 1/8/20 3:11 PM, Ahmed Zaki wrote:
> Hello,
> I am using libmicrohttpd (0.9.69) in a RestFul API server that uses
> Digest authentication. All the endpoints are working fine except for a
> PUT on one of the endpoints where the client uploads a large
> (12~13MBytes) file to the application. This fails on all browsers/OSs
> expect Chrome on Ubuntu.
> Using wireshark, I was able to see that:
> 1- The client/browser sends the initial PUT request and starts
> uploading the file.
> 2- After few msecs and part of the file uploaded, the
> application/libmicorohttpd sends the Auth fail 401 response (with new
> nonce).
> 3- This is immediately followed by the application/libmicrohttpd
> closing the TCP connection.
> 4- Only Chrome on Ubuntu re-opens a new TCP connection and uses the
> new nonce and hence the API request is accepted and the file is
> uploaded. Other browsers simply abort and show an error message.
> On all other endpoints, the initial API request, the 401 reply from
> the application/libmicrohttpd, and subsequent API request all happen
> on the same TCP connection, as expected.
> There is nothing different in how our application interacts with
> libmicrohttpd in regards to this endpoint, so I am suspecting that for
> some reason libmicrohttpd closes the TCP connection. Is there a way to
> prevent that? or even gain more insight on to why it is closing the
> connection?
> Any help would be appreciated.
> Thank you,
> Ahmed
> -----------------
> Other info:
> 1 - This issue is happening in development settings, so there are no
> other connections to the application/libmicorohttpd
> 3- MHD_OPTION_THREAD_POOL_SIZE, pool size 10
> 4- MHD_OPTION_CONNECTION_TIMEOUT, timeout 3 seconds

Attachment: close.diff
Description: Text Data

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]