[Mono-list] mod_mono/XSP HEAD (source) + Mono 1.0.5 (source)+ Apache 2 (binary) + Debian Sarge

[Gonzalo Paniagua Javier]

On Sun, 2005-01-30 at 20:45 +0100, Winfried Harbecke wrote:
> Hi,
> 
>   I don't know if someone else has figured this out before,
>   but I could not find any evidence to that so far ...
> 
>   My findings provide an explanation why some
>   people fare better with apache installed from source
>   when setting up mod_mono, and they also explain why
>   some people have symptoms that point to a version
>   inconsistency betweeen mod_mono.so and mod_mono_server
>   although they promise they don't have any inconsistecy
>   at all. I'll also post what I did to provide some
>   help with debugging mod_mono - to help improving future
>   bug reports and support requests    :-).
> 
>   Skimming recent postings on the Mono list, I noticed that
>   there are a few bugs that were only fixed in the 1.0.5 version
>   of the mod_mono/XSP packages. Thus, a combination of Mono 1.0.5
>   with an up-to-date version of mod_mono/XSP seemed like the
>   most promising combination. I installed Debian Sarge onto a
>   new partition, pulled in the prerequisites and compiled
>   Mono 1.0.5 from the released tarballs. I also obtained
>   the HEAD versions of mod_mono and XSP and compiled them - after
>   getting the apache development package from Debian testing.
> 
>   Starting mod-mono-server from command line to see the output,  I got 
> 
>                In ModMonoWorker.Run: Abnormal string size.
> 
>   and a 500 Internal Server Error in Apache.
> 
>   I added a couple DEBUG_PRINT's and some hex output to mod_mono.c,
>   and found
> 
>   [Sat Jan 29 12:29:01 2005] [warn] write_string_to_buffer (8:134217728)
>   [Sat Jan 29 12:29:01 2005] [warn]    length prefix 00 00 00 08
>   [Sat Jan 29 12:29:01 2005] [warn] write_data (44) bytes
>   [Sat Jan 29 12:29:01 2005] [warn]    01 00 00 00 03 47 45 54  .....GET
>   [Sat Jan 29 12:29:01 2005] [warn]    00 00 00 10 2f 64 65 6d  ..../dem
>   [Sat Jan 29 12:29:01 2005] [warn]    6f 2f 69 6e 64 65 78 2e  o/index.
>   [Sat Jan 29 12:29:01 2005] [warn]    61 73 70 78 00 00 00 00  aspx....
>   [Sat Jan 29 12:29:01 2005] [warn]    00 00 00 08 48 54 54 50  ....HTTP
>   [Sat Jan 29 12:29:01 2005] [warn]    2f 31 2e 31              /1.1....
> 
>   in /var/log/apache2/error.log. Running cpp against mod_mono.c
>   like the Makefile does (just replacing "-c" with "-E") gives
> 
>          lel = ((unsigned int) \
>   ( (((unsigned int) (l) & (unsigned int) 0x000000ffU) << 24) \
>   | (((unsigned int) (l) & (unsigned int) 0x0000ff00U) << 8) \
>   | (((unsigned int) (l) & (unsigned int) 0x00ff0000U) >> 8) \
>   | (((unsigned int) (l) & (unsigned int) 0xff000000U) >> 24)));
> 
>   At this point, I noticed that /usr/include/apache2/ap_config_auto.h
>   (in the Apache 2 development package) has
>    #define WORDS_BIGENDIAN 1
> 
>   which really messes things up, at least on an Intel machine    :-).
> 
>   After changing that to 
>    #undef WORDS_BIGENDIAN
>   I finally got to look at the first ASP.
> 
>   I could post a bug report for apache-debian, but I would not
>   expect anybody running into these symptoms to check that bug list    :-)

That's weird. It didn't happen to me because i compiled apache2 from
source instead of using the .deb.

>  
>   Gonzalo, I can provide patches for the hex output (it's
>   boilerplate stuff, though); I could also write up a few lines
>   to add to the FAQ. What I am really curious about is the
>   more fundamental question:

No need to add anything to the FAQ if we fix endianness detection even
on those systems.

> 
>   Why is mod_mono_server implemented as a standalone server
>   instead of baseing it on an embedded Mono runtime, which would
>   also be much closer to the Apache plug-in architecture? Licensing
>   issues?

The first mod_mono by Daniel Ridruejo tried to do that and didn't
succeed. May be because of problems with the mono runtime (it was long
time ago) or whatnot.

Another reason is that you can have several different machines running
apache and forwarding asp.net requests to a single machine, thus not
losing any state information (if using InProc) and not losing the
precompiled/cached stuff.

-Gonzalo