On 25.10.2005., at 16:41, Sébastien Arnaud wrote:
Hi Marko,
I think you were able to pinpoint even more the problem. It seems
indeed that Keep-alive/Content-length might lead us to one of the
bugs. I do have cherokee built on PPC linux (KuroBox HG) and it
works great, so I agree that it is not linked to big-edian issues
either.
found it!
ironicly it's the exact same problem of my original posting.
for example with a hack like this:
#define FMT_OFFSET "%llu"
cherokee_buffer_add_va (buffer, "Content-Length: "
FMT_OFFSET CRLF, length);
in hander_file.c:527
it seems that works (even with kqueue).
Explanation: on macosx off_t is 8 bytes long. It pushes on the stack
8 bytes, and since it is a big endian machine
when the "buffer_add_va" access it as 4 byte wide data it accesses
the most significant 4 bytes with are 0 for
when the offset is under 4*10^9...
With content-length always 0 the browsers was pretty confused,
expecially with multiple requests with keep-alive...
How this could leed to file descriptor related problems that showed
up (writing to closed descriptors, etc) using kqueue,
while after fixing this all seems to work is a little mistery for me...
obviously we have to find correct the problem at the root, that is
macro.h
/* Format string for off_t
*/
#if _FILE_OFFSET_BITS == 64
# define FMT_OFFSET "%llu"
# define CST_OFFSET unsigned long long
#else
# define FMT_OFFSET "%lu"
# define CST_OFFSET unsigned long
#endif
It should define _FILE_OFFSET_BITS on the macosx platform
in config.h I see
/* Number of bits in a file offset, on hosts where this is settable. */
/* #undef _FILE_OFFSET_BITS */
someone knowns well the autoconf/automake
marko_______________________________________________
Cherokee mailing list
[email protected]
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
