[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] size MHD_SIZE_UNKNOWN should never be returned in he
From: |
Christian Grothoff |
Subject: |
Re: [libmicrohttpd] size MHD_SIZE_UNKNOWN should never be returned in header |
Date: |
Thu, 1 Apr 2010 11:09:16 +0200 |
User-agent: |
KMail/1.12.4 (Linux/2.6.32-trunk-vserver-amd64; KDE/4.3.4; x86_64; ; ) |
Hi!
I've looked all over the code and I cannot find any size_t/uint64_t confusion
that would explain this. If you were using MHD_SIZE_UNKNOWN in conjunction
with "MHD_create_response_from_data", bad things would happen (since that's
not allowed by the API), but other than that I cannot see how this could be:
"total_size" is set ONLY in the "create_response_from_callback" and then
compared directly with MHD_SIZE_UNKNOWN.
If you have a testcase (not with IE but using libcurl as a client) that checks
for this and can reproduce it (at least on 32-bit archs), that would be very
helpful. As it stands, I cannot reproduce this -- and your patch, as you
mention, is certainly rather unclean (and would break 4 GB -1byte transfers).
Happy hacking!
Christian
On Thursday 01 April 2010 10:15:09 am Brecht Sanders wrote:
> Hi,
> I use libmicrohttpd on Windows (compiled under MSYS/MinGW).
> I have been looking at why my dynamic pages (using
> MHD_create_response_from_callback) would not display on Internet
> Explorer (version 6) while they were fine on Firefox.
> Finally I found it: the header returned includes:
> Content-Length: 4294967295
> This is 0xFFFFFFFF.
> In the code I see:
> #define MHD_SIZE_UNKNOWN ((uint64_t) -1LL)
> which probably corresponds, assuming you use uint64_t for size
> everywhere and don't mix with size_t.
> My first thought to fix this was to not return the length if it is
> MHD_SIZE_UNKNOWN.
> However, on my platform the (MHD_SIZE_UNKNOWN !=
> connection->response->total_size) comparison didn't seem to match.
> I worked around it for now with the patch below using size_t typecasts.
> However I suspect an underlying problem where size gets truncated from
> uint64_t to a smaller type (maybe size_t) somewhere else.
> So my patch is not the perfect fix in case you will have file larger
> than 4G.
> Regards
> Brecht Sanders
>
>
> patch -ulb src/daemon/connection.c << EOF
> --- src/daemon/connection.c 2010-03-11 13:34:20 +0100
> +++ src/daemon/connection.c 2010-04-01 10:02:50 +0200
> @@ -498,4 +498,5 @@
> }
> - else if (NULL == MHD_get_response_header (connection->response,
> -
> MHD_HTTP_HEADER_CONTENT_LENGTH))
> + else if ((NULL == MHD_get_response_header (connection->response,
> +
> MHD_HTTP_HEADER_CONTENT_LENGTH)) &&
> + ((size_t)MHD_SIZE_UNKNOWN !=
> (size_t)connection->response->total_size))
> {
> EOF
>