From owner-freebsd-questions@FreeBSD.ORG Mon Oct 8 18:35:10 2012 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D41DF106564A for ; Mon, 8 Oct 2012 18:35:10 +0000 (UTC) (envelope-from toomas.aas@raad.tartu.ee) Received: from kuller.raad.tartu.ee (kuller.raad.tartu.ee [213.184.43.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8299C8FC14 for ; Mon, 8 Oct 2012 18:35:10 +0000 (UTC) Received: from kuller.raad.tartu.ee (localhost [127.0.0.1]) by kuller.raad.tartu.ee (Postfix) with ESMTP id 5460339821 for ; Mon, 8 Oct 2012 21:29:30 +0300 (EEST) X-Virus-Scanned: amavisd-new at post.raad.tartu.ee Received: from kuller.raad.tartu.ee ([127.0.0.1]) by kuller.raad.tartu.ee (kuller.raad.tartu.ee [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ozwbLq7OXaIS for ; Mon, 8 Oct 2012 21:29:29 +0300 (EEST) Received: by kuller.raad.tartu.ee (Postfix, from userid 80) id BCBFC3981F; Mon, 8 Oct 2012 21:29:28 +0300 (EEST) Received: from 76.20.190.90.dyn.estpak.ee (76.20.190.90.dyn.estpak.ee [90.190.20.76]) by webmail.raad.tartu.ee (Horde Framework) with HTTP; Mon, 08 Oct 2012 21:29:28 +0300 Message-ID: <20121008212928.10685a2gxotv2lc0@webmail.raad.tartu.ee> Date: Mon, 08 Oct 2012 21:29:28 +0300 From: Toomas Aas To: questions@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) X-Originating-IP: 90.190.20.76 Cc: Subject: A strange regression in curl X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 18:35:10 -0000 Hello! We have a web application running on FreeBSD 7.4 (amd64) which uses libcurl to send data to another system via HTTPS POST request. After I upgraded curl from 7.19.6 to 7.24, a mysterious problem appeared. When the length of the POSTed form exceeds 16121 bytes, sending the POST request to another system fails (receiving system responds with Error 500 and writes in its log 'Invalid POST Request received'). Admin of the receiving system says that his system never sees more than 16121 bytes of the incoming POST request. The problem does not appear when sending requests over HTTP instead of HTTPS, but this is no solution due to security requirements. Also I'm told that the problem does not appear when sending requests with curl 7.24 on Linux (don't know which distro). I downgraded curl back to 7.21.3, and the problem seems to have disappeared. I have output of curl --trace from versions 7.24 and 7.21.3, but looking at these two outputs they seem rather similar to me. Interesting thing is that both versions do seem to send the data in two "batches", as seen in the output of --trace. In my test case, after successful SSL negotioation, I see the following actions: Send header, 263 bytes Send data, 16121 bytes Send data, 890 bytes Note how the first "Send data" is 16121 bytes, which is also the size limit where requests start to fail with curl 7.24. It seems that in case of curl 7.24 the receiving server does not receive the second part of "Send data" and thus sees the request as broken. But what is actually the problem? I don't think I can remain with curl 7.21.3 indefinitely... -- Toomas Aas