libmicrohttpd
[Top][All Lists]
Advanced

[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
> 




reply via email to

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