[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] MHDs handling of HEADs and Content-Length
From: |
Christian Grothoff |
Subject: |
Re: [libmicrohttpd] MHDs handling of HEADs and Content-Length |
Date: |
Tue, 23 Apr 2019 19:36:58 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
Hi Damon,
I've tried to reproduce the issue, and for me MHD with HEAD responds
with the correct non-zero content length. Maybe your code contains some
subtle difference in how you call
MHD_create_response_from_fd_at_offse64()? If not, some minimal example
to reproduce the issue would be helpful.
happy hacking!
Christian
On 4/23/19 5:54 PM, Damon Earp wrote:
> I started playing with newer versions of libmicrohttpd recently noticed
> an issue with HEAD requests after bumping up the library version from
> 0.9.51 to 0.9.63.
>
> Platform: Debian 9.8 amd64
> $ uname -a
> Linux somehostname 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27)
> x86_64 GNU/Linux
> $ sudo apt show libmicrohttpd12
> Package: libmicrohttpd12
> Version: 0.9.51-1
>
> For both HEAD and GET requests I have been creating my response with
> MHD_create_response_from_fd_at_offset64 and regardless of the method
> type the Content-Length header was always set correctly. In other words,
> I depend on libmicrohttpd to set the Content-Length header correctly for
> both types of requests and never explicitly set it.
>
> Seeing as 0.9.51 is 2.5 years old I decided to try 0.9.63, I custom
> built a shared library w/ a deb package for it
> $ curl -LO --get
> https://ftp.gnu.org/gnu/libmicrohttpd/libmicrohttpd-0.9.63.tar.gz
> ...
> $ ./configure --with-pic --prefix=/usr
> --libdir=/usr/lib/x86_64-linux-gnu --enable-https --disable-curl
> --disable-doc --disable-examples --enable-static=no
>
> After installing the new version of the library my HEAD requests started
> responding with "Content-Length: 0", and GETs continued to have the
> correct value. Other than that everything else is working without a hitch.
>
> If this is a bug, let me know if you need more information. Or if this
> is my misunderstanding of the statement "The library does understand
> HEAD and will only send the headers of the response and not the body,
> even if the client supplied a body." please let me know.
>
> Thanks for this great library!
> Damon
signature.asc
Description: OpenPGP digital signature