jacksonh / manos

Manos is an easy to use, easy to test, high performance web application framework that stays out of your way and makes your life ridiculously simple.

NOTE: this project is not under active development anymore. I encourage you to play with it, learn from it, use it as a platform for innovation. I wont discourage you from using it in production, some people are, but I will encourage you to evaluate more supported technologies like SignalR (or perhaps non .NET technologies like node.js)

Manos is an easy to use, easy to test, high performance web application framework that stays out of your way and makes your life ridiculously simple.

The Main Features of Manos:

• Manos creates stand alone web applications that don't rely on Apache, IIS or any other web server, the server is bundled into the .exe file with the rest of your application. This allows for easy deployment, easy upgrades and absolutely no configuration.

• High performance and scalable. Modeled after tornadoweb, the technology that powers friend feed, Manos is capable of thousands of simultaneous connections, ideal for applications that create persistent connections with the server.

• Testing built in from the beginning making things testable was a primary concern on Manos. This means you can easily Mock just about any object in the Manos stack, making testing your application dead simple.

For installation instructions please read the installation guide in the docs directory.

manos's Issues

Manos.Http\HttpException.cs defined twice in Manos.csproj

Title says it all, and Visual Studio refuses to build until the second definition is removed.

Request for new Route() overload

Any chance this overload for the Route() method can be added (includes an extra final parameter to declare the http methods to match).

public RouteHandler Route(string pattern, MatchType matchType, ManosAction action, HttpMethod[] methods)
{
    IMatchOperation[] ops = OpsForPatterns(new string[] { pattern }, matchType);
    return AddRouteHandler(action, ops, methods);
}

I'm building a lightweight MVC framework around Manos and so far this is the only change I've had to make to Manos itself.

manos -s exception when following the getting started docs (step 1)

Following along with page 1 of the tutorial, an exception is generated when trying to serve the Shorty application: http://gist.github.com/619757

The app was compiled using

 gmcs -target:library -pkg:manos -out:Shorty.dll Shorty.cs StaticContentModule.cs

This is on OSX 10.6.4 with Mono 2.8. Libev and libev_sharp are both installed.

SendFile does not work on OSX

manos OSx86:courageapp$ manos -s
Running courageapp.courageapp on port 8080.
error while serving application:
System.NullReferenceException: Object reference not set to an instance of an object
at Manos.IO.SendFileOperation.HandleWrite (Manos.IO.IOStream) <0x001bc>
at Manos.IO.IOStream.HandleWrite () <0x00030>
at Manos.IO.IOStream.HandleIOWriteEvent (Libev.Loop,Libev.IOWatcher,Libev.EventTypes) <0x0008f>
at Libev.IOWatcher.UnmanagedCallbackHandler (intptr,intptr,Libev.EventTypes) <0x00017>
at (wrapper native-to-managed) Libev.IOWatcher.UnmanagedCallbackHandler (intptr,intptr,Libev.EventTypes) <0x0003b>
at (wrapper managed-to-native) Libev.Loop.ev_run (intptr,Libev.LoopType) <0x00003>
at Libev.Loop.Run (Libev.LoopType) <0x0002c>
at Libev.Loop.RunBlocking () <0x00020>
at Manos.IO.IOLoop.Start () <0x0001a>
at Manos.AppHost.Start (Manos.ManosApp) <0x000ef>
at Manos.Tool.ServerCommand.Run () <0x000c1>
at Manos.Tool.Driver.RunServer (System.Collections.Generic.IList1<string>) <0x0023d> at Manos.Tool.Driver.Server (System.Collections.Generic.IList1) <0x00034>

UriParser doesn't handle authority

The UriParser needs to be able to handle the authority section of uris. usernames and password:

http://username:[email protected]

reset UploadedFiles cache (too)

Similarly to Cookies, UploadedFiles needs to be fixed:

diff --git a/src/Manos/Manos.Http/HttpEntity.cs b/src/Manos/Manos.Http/HttpEntity.cs
old mode 100644
new mode 100755
index 72b70e6..5ef86e6
--- a/src/Manos/Manos.Http/HttpEntity.cs
+++ b/src/Manos/Manos.Http/HttpEntity.cs
@@ -382,6 +382,7 @@ namespace Manos.Http {
            headers = null;
            data = null;
            post_data = null;
+           uploaded_files = null;
 
            if (parser_settings == null)
                CreateParserSettingsInternal ();

Problem with async writing to response (using Boundary)

Let's assume I have a project with file downloading. Files are contained on other server and can be downloaded from it using own protocol via sockets. First let's see handler:

        private void GetFile(IManosContext ctx, string pathAndFileName)
        {
            SessionObject session;
            if (CheckAndGetSession(ctx, out session))
            {
                Boundary.Instance.ExecuteOnTargetLoop(() => PerformDownload(ctx, session, pathAndFileName));
            }
        }

The PerformDownload method is quite long (because it deals with mentioned protocol), but it writes to response chunks of data using ctx.Response.Write(array of bytes here) and finishing it with ctx.Response.End() (after all chunks are written). If there are a lot of data to write, response seen by web browser is corrupted (seems to be truncated) and almost always in the same way. Protocol is quite well tested, I also have another (local app) client which works fine with many asynchronous downloads. Also arrays of bytes given to ctx.Response.Write() are never reused, so this is probably not corruption of data buffer before writing.

I also used a version with Boundary.Instance.ExecuteOnTargetLoop called on every write and end (and with method called directly) with no more luck (however I consider such approach more proper, changed it only to see if it helps).

Is it proper way to do that?

Latest Manos fails to build on Windows

SendFileOperation.Dispose() isn't implemented in SendFileOperation_NO_SENDFILE.cs

Here's a patch

diff --git a/src/Manos/Manos.IO/SendFileOperation_NO_SENDFILE.cs b/src/Manos/Manos.IO/SendFileOperation_NO_SENDFILE.cs
index b524470..f96239b 100644
--- a/src/Manos/Manos.IO/SendFileOperation_NO_SENDFILE.cs
+++ b/src/Manos/Manos.IO/SendFileOperation_NO_SENDFILE.cs
@@ -46,8 +46,13 @@ namespace Manos.IO {
        private int bytes_index;

        private FileStream file;
-       private int file_length;
-       
+       private int file_length;
+
+       public void Dispose()
+       {
+           file.Dispose();
+       }
+
        public SendFileOperation (FileStream file, WriteCallback callback)
        {
            this.file = file;

NullReferenceException on multipart upload

I'm using Manos to handle large file uploads, and when I upload an image from Google Chrome to the upload handler, it throws a NullDereferenceException in the parser.

It appears to be related to Chrome sending some blank entries.

I've pasted all the output Manos de Mono makes, as well as the complete request headers and entity. This is a debug compilation, so line numbers are included.

https://gist.github.com/769165

autogen should search for glibtoolize and glibtool on OS X

Build fails unless I manually modify autogen.sh.

No Windows Support

Hi! I've tried to build the latest source but received many errors reporting that EpollEvent and EpollEvents types couldn't be found. I'm building with VS.NET 2010/Win7 with Mono 2.6.7 installed. Any idea?

Manos doesn't respond to requests under Windows

Manos doesn't respond to requests. I'm guessing this is only an issue when running on Windows, as you'd probably have noticed otherwise.

This bug reproduces with both my app, and the docs app built into manostool.exe.

Manos receives the requests as info is printed to the console, but no response is sent for a period of time before the connection is closed by Manos.

I realise this bug report contains little info to go on, so let me know what additional information you need to investigate this further.

Split into .IO and .Core

I think we should split Manos into Manos.IO and Manos.Core. .IO would contain all the async IO stuff (files, sockets, watchers), while .Core would contain all of the rest. The split would not be much work, and after the split we could integrate the IO framework into other apps (eg to build a better benchmark tool than ab, that clearly doesn't need a full HTTP parser), not to mention the ability to hide implementation details (libev for example) from IO users. That missing abstraction made some of the latest bugs at all possible.

As already mentioned, the split can be done rather quickly. Moving all the IO parts into one assembly and all the current server stuff into another is no complex task.

Cookie value retrieval on the same key looks wrong

In the following code, I try to get a cookie value which was set by the previous call that ends with Response.Redirect(). On every request, it should overwrite the previous cookie, and on wireshark I see my firefox actually receives and sends the newer cookie value on HTTP 302 and the following request. But at manos side I get older cookie value on HttpRequest.Cookies:

using System;
using Manos;

namespace foobar {

        public class foobar : ManosApp {

                public foobar ()
                {
                        Route ("/Content/", new StaticContentModule ());
                }

                [Route ("/")]
                public void Index (IManosContext ctx)
                {
                        ctx.Response.SetCookie ("foobarcookie", DateTime.Now.ToString ("HH:mm.ss"), DateTime.Now.AddHours (1));
                        ctx.Response.Redirect ("/redirected");
                }

                [Route ("/redirected")]
                public void Redirected (IManosContext ctx)
                {
                        ctx.Response.Headers.SetHeader ("Cache-Control", "no-cache");
                        ctx.Response.Headers.SetHeader ("Pragma", "no-cache");
                        ctx.Response.End ("cookie is " + ctx.Request.Cookies ["foobarcookie"] + ". try again</a></body></html>");
                }
        }
}

Every time I click "try again" link, I see the cookie value keep showing the first-time value.

Though I'm not really sure if this kind of cookie retrieval should work.

Manos/HTTPS

This is less of an issue and more of an improvement, actually: I think Manos could benefit from supporting HTTPS connections.

How to run synchronous blocking logic efficiently in Manos

I'm wondering what the most efficient approach is to run a synchronous code block (that makes io/db calls). Is manos designed to support this scenario? is this in the roadmap and do you have examples (preferably using OWIN interfaces :)?

manos swallows '+' in inputs from multipart/form-data

With the foobar app below, enter "a+b" and click "post" button to see the input results. It will show "a b / a b" instead of "a+b / a+b", probably due to URL encoding the inputs. (Two results are from Request.Data["foobar"] and method parameter foobar.)

using Manos;

namespace foobar {
        public class foobar : ManosApp {
                public foobar ()
                {
                        Route ("/Content/", new StaticContentModule ());
                }

                [Route ("/")]
                public void ShowForm (IManosContext ctx)
                {
                        ctx.Response.End (@"
<html> <body> <form action='/send' method='POST' enctype='multipart/form-data'>
<input type='text' name='foobar' />
<input type='submit' value='post' />
</form> </body> </html>");
                }

                [Route ("/send")]
                public void Receive (IManosContext ctx, string foobar)
                {
                        ctx.Response.End ("'{0}' / '{1}'", ctx.Request.Data ["foobar"], foobar);
                }
        }
}

This happens only when multipart/form-data is specified.

Creates page_base twice, thus not letting me render.

I compiled the kayak demo in the demos section, pared it down, and tried to render with the following code:
Minge.Initialize("templates");
Minge.RenderToStream("base.html", Console.Out);
When it runs, I get a the following exception:
System.BadImageFormatException was unhandled
Message="Duplicate type with name 'templates.page_base' in assembly 'minge-compiled-templates, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'."

And when I open it in Reflector, I see two page_base classes in minge-compiled -templates.

Missing </html> tag in tutorial and example app

Just a small fixup patch to add the missing tag in both tutorial (page-2) and Shorty app in examples/

Patch linkie: http://neteril.org/~jeremie/tmp/0001-Fix-missing-closing-html-tag-in-tutorial-and-Shorty-.patch

TimeOut.cs - ShouldContinueToRepeat

public bool ShouldContinueToRepeat ()
{
  return !stopped || repeat.ShouldContinueToRepeat ();  
}

should be -
return stopped || repeat.ShouldContinueToRepeat ();

-snip-

-snip-

data/layouts is not being copied to /usr/local/share/manos/layouts on make install

This prevents generation from templates from working.

Unit tests fail to build

I guess there's been some refactoring since the last time anybody ran these:

Building: Manos.Tests (Debug)

Performing main compilation...
/home/sandy/stage/mono-2-10/bin/dmcs /noconfig "/out:/home/sandy/random-code/manos/build/Manos.Tests.dll" "/r:/usr/lib/cli/nunit.framework-2.4/nunit.framework.dll" "/r:/home/sandy/random-code/manos/build/Manos.dll" "/r:/home/sandy/stage/mono-2-10/lib/mono/4.0/System.dll" "/r:/home/sandy/stage/mono-2-10/lib/mono/4.0/System.Core.dll" /nologo /warn:4 /debug:+ /debug:full /optimize- /codepage:utf8 /platform:x86 "/define:DEBUG" /t:library "/home/sandy/random-code/manos/src/Manos.Tests/Manos/ManosModuleTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/RouteHandlerTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/RegexMatchOperationTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/MatchOperationFactoryTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/StringMatchOperationTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/NopMatchOperationTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Http/HttpRequestTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Http/HttpHeadersTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos/InfiniteRepeatBehaviorTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos/RepeatBehaviorTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos/AppHostTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Caching/ManosInProcCacheTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ParameterizedActionTargetTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ActionTargetTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ParameterizedActionTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/SimpleMatchOperationTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Nunit-Extensions/Nunit_Extension_Methods.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Collections/DataDictionaryTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Http/HttpCookieTest.cs" "/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/HtmlFormDataTypeConverterTest.cs" "/nowarn:1591"
Compilation failed: 17 error(s), 0 warnings

/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/RouteHandlerTest.cs(104,31): error CS1729: The type Manos.Http.Testing.MockHttpTransaction' does not contain a constructor that takes1' arguments
/home/sandy/random-code/manos/build/Manos.dll (Location of the symbol related to previous error)
/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/RouteHandlerTest.cs(114,35): error CS1729: The type Manos.Http.Testing.MockHttpTransaction' does not contain a constructor that takes1' arguments
/home/sandy/random-code/manos/build/Manos.dll (Location of the symbol related to previous error)
/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/RouteHandlerTest.cs(120,27): error CS1729: The type Manos.Http.Testing.MockHttpTransaction' does not contain a constructor that takes1' arguments
/home/sandy/random-code/manos/build/Manos.dll (Location of the symbol related to previous error)
/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/RouteHandlerTest.cs(132,35): error CS1729: The type Manos.Http.Testing.MockHttpTransaction' does not contain a constructor that takes1' arguments
/home/sandy/random-code/manos/build/Manos.dll (Location of the symbol related to previous error)
/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/RouteHandlerTest.cs(138,27): error CS1729: The type Manos.Http.Testing.MockHttpTransaction' does not contain a constructor that takes1' arguments
/home/sandy/random-code/manos/build/Manos.dll (Location of the symbol related to previous error)
/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ParameterizedActionTargetTest.cs(81,68): error CS1502: The best overloaded method match for Manos.Routing.ParameterizedActionTarget.TryConvertType(Manos.IManosContext, string, System.Reflection.ParameterInfo, out object)' has some invalid arguments /home/sandy/random-code/manos/build/Manos.dll (Location of the symbol related to previous error) /home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ParameterizedActionTargetTest.cs(81,68): error CS1503: Argument#2' cannot convert System.Type' expression to typestring'
/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ParameterizedActionTargetTest.cs(92,51): error CS1502: The best overloaded method match for Manos.Routing.ParameterizedActionTarget.TryConvertType(Manos.IManosContext, string, System.Reflection.ParameterInfo, out object)' has some invalid arguments /home/sandy/random-code/manos/build/Manos.dll (Location of the symbol related to previous error) /home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ParameterizedActionTargetTest.cs(92,51): error CS1503: Argument#2' cannot convert System.Type' expression to typestring'
/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ParameterizedActionTargetTest.cs(102,68): error CS1502: The best overloaded method match for Manos.Routing.ParameterizedActionTarget.TryConvertType(Manos.IManosContext, string, System.Reflection.ParameterInfo, out object)' has some invalid arguments /home/sandy/random-code/manos/build/Manos.dll (Location of the symbol related to previous error) /home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ParameterizedActionTargetTest.cs(102,68): error CS1503: Argument#2' cannot convert System.Type' expression to typestring'
/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ParameterizedActionTargetTest.cs(113,51): error CS1502: The best overloaded method match for Manos.Routing.ParameterizedActionTarget.TryConvertType(Manos.IManosContext, string, System.Reflection.ParameterInfo, out object)' has some invalid arguments /home/sandy/random-code/manos/build/Manos.dll (Location of the symbol related to previous error) /home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ParameterizedActionTargetTest.cs(113,51): error CS1503: Argument#2' cannot convert System.Type' expression to typestring'
/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ParameterizedActionTargetTest.cs(123,68): error CS1502: The best overloaded method match for Manos.Routing.ParameterizedActionTarget.TryConvertType(Manos.IManosContext, string, System.Reflection.ParameterInfo, out object)' has some invalid arguments /home/sandy/random-code/manos/build/Manos.dll (Location of the symbol related to previous error) /home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ParameterizedActionTargetTest.cs(123,68): error CS1503: Argument#2' cannot convert System.Type' expression to typestring'
/home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ParameterizedActionTargetTest.cs(134,51): error CS1502: The best overloaded method match for Manos.Routing.ParameterizedActionTarget.TryConvertType(Manos.IManosContext, string, System.Reflection.ParameterInfo, out object)' has some invalid arguments /home/sandy/random-code/manos/build/Manos.dll (Location of the symbol related to previous error) /home/sandy/random-code/manos/src/Manos.Tests/Manos.Routing/ParameterizedActionTargetTest.cs(134,51): error CS1503: Argument#2' cannot convert System.Type' expression to typestring'

Build complete -- 17 errors, 1 warning

---------------------- Done ----------------------

Reference 'nunit.framework' not found on system. Using 'nunit.framework, Version=2.4.7.0, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77' instead.
Build: 17 errors, 1 warning

libmanos does not support IPv6

libmanos does not support IPv6, and SocketStream does not either as a consequence. Passing the parsed protocol family (PF_INET for AF_INET, INET6 accordingly) into create_socket should fix this, though.

Malformed HTTP request => segfault

Malformed HTTP requests crash the HTTP parser, or even the whole process. Eg, telnet to the listener socket and ask it for "HTTP/1.1 GET /". Or for "GET / HTTP/1.1" on Linux.

on windows, Boundary makes an incorrect assumption about loop type

Using git version 05935cd

Unhandled Exception: System.TypeInitializationException: The type initializer for 'Manos.Threading.Boundary' threw an exception. ---> System.InvalidCastException: Unable to cast object of type 'Manos.Managed.ManagedLoop' to type 'Libev.LibEvLoop'.
   at Manos.Threading.Boundary..ctor(IOLoop loop, Int32 maxWorkPerLoop) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Threading\Boundary.cs:line 47
   at Manos.Threading.Boundary..ctor(IOLoop loop) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Threading\Boundary.cs:line 44
   at Manos.Threading.Boundary..cctor() in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Threading\Boundary.cs:line 36
   --- End of inner exception stack trace ---
   at Manos.Managed.Libeio.<>c__DisplayClass13.<open>b__10(Object a) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Managed\Libeio.cs:line 77
   at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
   at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

In a request handler, I attempted to use IHTTPResponse.SendFile("foo.html"). This exception seems to have occurred in a background thread while that was attempting to complete.

fails to render output from top to probably-last-buffered data

The following sample app gives weird output as pasted below. This looks like the output contains only the final chunk of buffer written to HTTP output.

-------- (you can just create this by running "manos -init test" and adding Foobar method in the output "test.cs" ----

using Manos;

namespace manostest {

    public class manostest : ManosApp {

            public manostest ()
            {
                    Route ("/Content/", new StaticContentModule ());
            }

            [Route ("/foobar")]
            public void FooBar (IManosContext ctx)
            {
                    for (int i = 0; i < 100; i++) {
                            string s = new string ('0', 54) + i + "\n";
                            ctx.Response.Writer.Write (s);
                    }
                    ctx.Response.Writer.Flush ();
                    ctx.Response.End ();
            }
    }
}

The output looks like:

00000000000000000000000000000000000000000000000000000090
00000000000000000000000000000000000000000000000000000091
00000000000000000000000000000000000000000000000000000092
00000000000000000000000000000000000000000000000000000093
00000000000000000000000000000000000000000000000000000094
00000000000000000000000000000000000000000000000000000095
00000000000000000000000000000000000000000000000000000096
00000000000000000000000000000000000000000000000000000097
00000000000000000000000000000000000000000000000000000098
00000000000000000000000000000000000000000000000000000099
000000000000000000000000000000000000000000000000000082
00000000000000000000000000000000000000000000000000000083
00000000000000000000000000000000000000000000000000000084
00000000000000000000000000000000000000000000000000000085
00000000000000000000000000000000000000000000000000000086
00000000000000000000000000000000000000000000000000000087
00000000000000000000000000000000000000000000000000000088
00000000000000000000000000000000000000000000000000000089
00000000000000000000000000000000000000000000000000000090
00000000000000000000000000000000000000000000000000000091
00000000000000000000000000000000000000000000000000000092
00000000000000000000000000000000000000000000000000000093
... (the same buffer repeats)

Parameter based routing not working as expected in a module

I have an App and a module. When I do this in an app everything works as it should using curl http://localhost:5050/Hello/10/.

    [Route("/Hello/{id}/")]
    public void Update(IManosContext ctx, string id)
    {
        Console.WriteLine("Hello {0}", id);
        ctx.Response.Redirect("/Blog/");
    }

But when I do the same thing in a module the {id} but is not working and the code never gets called when using curl http://localhost:5050/Blog/Update/10/. In my App I have this:
Route("/Blog/", new BlogModule());

And in the module itself I got this:
[Route("Update/{id}/")]
public void Update(IManosContext ctx, string id)
{
Console.WriteLine("Update {0}", id);
}

If there is anything else I can provide to help with this, let me know.

Design for Session State management

I realise that Manos currently doesn't include and session state management, but was wondering if anyone is working on this and whether there's been any thought into its design? I'm really going to need to this soon and I'm willing to write it myself but I want to make sure it fits with what's needed.

I'm familiar with ASP.NET's session state management which uses locking to ensure that only one client request per session can run at a time. I'm concerned that implementing something that blocks would have negative consequences for Manos and it's event driven model. Perhaps an asynchronous mechanism is required.

Thoughts?

HttpFormPostHandler does not handle empty input value correctly

manos does not handle form entries when there is an empty input text.

Repro:

1. manos -init foobar
2. Add the following methods in foobar.cs

            [Route ("/")]
            public void Index (IManosContext ctx)
            {
                    ctx.Response.End (@"

"); }

            [Route ("/a")]
            public void ProcessPost (IManosContext ctx)
            {
                    ctx.Response.End ("x = {0}, y = {1}",
                            ctx.Request.Data ["x"],
                            ctx.Request.Data ["y"]);
            }

3. manos -build
4. manos -server
5. Open http://localhost:8080/
6. Enter 'X' only in the second textbox and click 'send'

The result is shown as "x = , y=" which should actually be "x = , y = X"

The following change fixes the issue:

--- a/src/Manos/Manos.Http/HttpFormDataHandler.cs
+++ b/src/Manos/Manos.Http/HttpFormDataHandler.cs
@@ -88,8 +88,6 @@ namespace Manos.Http {

            private void FinishPair (HttpEntity entity)
            {

•                   if (value_buffer.Length == 0)
  

•                           return;
  

manos -d broken in master (regression from 0.1.3)

Not sure how to get info on what the actual error is, but when I point my browser at the manos instances showing the docs, I get:

404 - The page you were looking for doesn't exist.
You may have mistyped the address or the page may have moved.
Powered by manos

Git bisect says first bad commit is 7558905

Works fine in 0.1.3.

Memory Leak

The example where the memory leak occurs is here:
https://gist.github.com/873510

I'm calling re.WriteLine ~300 times, that results in a big memory consumption.
I tried using System.Console.WriteLine instead and it works just fine without using up this much memory.
I'll take a look at the code myself, but maybe you already fixed it or want to look over it as well :)

Routing documentation wrong

In routing.md there are some errors that make getting started with Manos difficult.

1. The examples for "Regular Expressions as Routes" and "Simple patterns are Routes" don't work because the attribute defaults to a match type of "Simple". So, for this to work:

   [Get ("/articles/{slug}/")]
   

   it should actually be:

   [Get("/articles/{slug}/", MatchType=Manos.Routing.MatchType.Simple)]
   

   Perhaps there should be a match type of "AutoDetect"

2. In "Explicitly routing methods using attributes" there's an example of applying a route attribute to a ManoModule property however this attribute can't be applied to properties - only methods.

Install documentation clarification for Windows

The document states:

"Checkout Manos from github at http://github.com/jacksonh/manos/ and build/install it using Visual Studio"

However for clarity, I think it would be good to state that you need to use Visual Studio 2010 or greater as the project uses .Net 4.0 features (like default parameters).

So I would tweak it to something like:

"Checkout Manos from github at http://github.com/jacksonh/manos/ and build/install it using Visual Studio 2010 or greater"

Would also be nice to have install instructions for people that don't use Visual Studio.

TimerWatcher ctor doesn't use the Repeat TimeSpan parameter

TimerWatcher.cs:

looks like

unmanaged_watcher.repeat = after.TotalSeconds;

should be

unmanaged_watcher.repeat = repeat.TotalSeconds;

Missing default parameter in HTTP request results in InvalidCastException

Create an app, add a method that takes a parameter which is without default value, like this:

    [Route ("/")]
    public void Index (IManosContext ctx, string notification)
    {
        ctx.Response.End ("TEST");
    }

Then build and run, and send a request to http://localhost:8080/ (i.e. without passing "?notification=foobar". You'll get:

Exception in transaction handler:
System.InvalidCastException: Cannot cast from source type to destination type.
at (wrapper dynamic-method) object. (object,object[]) <0x000e5>
at Manos.Routing.ParameterizedActionTarget.Invoke (Manos.ManosApp,Manos.IManosContext) <0x0009d>
at Manos.ManosApp.HandleTransaction (Manos.ManosApp,Manos.Http.IHttpTransaction) <0x0022c>

This is because the default parameter is not correctly guessed. Surprisingly, ParameterInfo.DefaultValue returns DBNull.Value instead of null (I didn't know that too).

Proposed fix:

diff --git a/src/Manos/Manos.Routing/ParameterizedActionTarget.cs b/src/Manos/Manos.Routing/ParameterizedActionTarget.cs
index 4894f99..3f44167 100644
--- a/src/Manos/Manos.Routing/ParameterizedActionTarget.cs
+++ b/src/Manos/Manos.Routing/ParameterizedActionTarget.cs
@@ -120,7 +120,7 @@ namespace Manos.Routing
            if (TryConvertFormData (type, str_value, out data))
                return true;
 
-           if (str_value == null && param.DefaultValue != null) {
+           if (str_value == null && param.DefaultValue != DBNull.Value) {
                data = param.DefaultValue;
                return true;
            }

Unicode support?

I'm trying to print some characters which are actively used by the rest of the world:
ctx.Response.WriteLine("ąčęėįšųūžöüöä");
This basically fails instantly, only "?" is printed out. Loading stuff from files doesn't work as well.

DllNotFound for libev.dll

I've gotten Manos to work flawlessly on my dev system, but when I upload all the files to my server, starting my app throws an exception in the Libev.Loop type initializer with the exception:

The type initializer for 'Libev.Loop' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'libev': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
   at Libev.Loop.ev_version_major()
   at Libev.Loop..cctor()
   at Libev.Loop.CreateDefaultLoop(UInt32 flags)
   at Manos.IO.IOLoop..ctor()
   at Manos.IO.IOLoop..cctor()
   at Manos.IO.IOLoop.get_Instance()
   at Manos.AppHost..cctor()
   at Manos.AppHost.set_IPAddress(IPAddress value)
   at UploadServer.Bootstrap.Main()

libev.dll is located in the same directory as all the other requires libraries.

Both the production server and my dev machine are x64, however the production machine in Windows Server 2008.

manos http server throws parse exceptions for valid requests

If I am running a manos http server on port 5000 of localhost, and I fetch http://localhost:5000/foo?abc, manos throws the following exception:

Manos.Http.HttpException: Exception of type 'Manos.Http.HttpException' was thrown.
   at Manos.Http.ParserSettings.RaiseOnError(HttpParser p, String message, ByteBuffer buf, Int32 ini_pos) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Http\ParserSettings.cs:line 82
   at Manos.Http.ParserSettings.Raise(HttpCallback cb, HttpParser p) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Http\ParserSettings.cs:line 135
   at Manos.Http.ParserSettings.RaiseOnMessageComplete(HttpParser p) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Http\ParserSettings.cs:line 61
   at Manos.Http.HttpParser.headers_almost_done(Int32 ch, ParserSettings settings, ByteBuffer data, Int32 p_err) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Http\HttpParser.cs:line 1617
   at Manos.Http.HttpParser.Execute(ParserSettings settings, ByteBuffer data) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Http\HttpParser.cs:line 1245
   at Manos.Http.HttpEntity.OnBytesRead(IIOStream stream, Byte[] data, Int32 offset, Int32 count) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Http\HttpEntity.cs:line 401
System.NullReferenceException: Object reference not set to an instance of an object.
   at Manos.Collections.DataDictionary.Set(String key, UnsafeString value) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Collections\DataDictionary.cs:line 193
   at Manos.Collections.DataDictionary.Set(String key, String value) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Collections\DataDictionary.cs:line 179
   at Manos.Http.HttpUtility.ParseUrlEncodedData(String data, Encoding encoding, DataDictionary result) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Http\HttpUtility.cs:line 234
   at Manos.Http.HttpUtility.ParseUrlEncodedData(String data, Encoding encoding) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Http\HttpUtility.cs:line 189
   at Manos.Http.HttpUtility.ParseUrlEncodedData(String data) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Http\HttpUtility.cs:line 174
   at Manos.Http.HttpRequest.OnFinishedReading(HttpParser parser) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Http\HttpRequest.cs:line 173
   at Manos.Http.HttpEntity.OnMessageComplete(HttpParser parser) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Http\HttpEntity.cs:line 271
   at Manos.Http.ParserSettings.Raise(HttpCallback cb, HttpParser p) in c:\cygwin\home\brian\projects\tood\manos\upstream\src\Manos\Manos.Http\ParserSettings.cs:line 131

The HTTP client connection is then abruptly shut down.

A few things seem worth mentioning:

1. the request is valid according to HTTP/1.1
2. This exception is happening at a fairly low level--in the http server itself, before higher-level framework-y stuff gets involved.
3. If manos as a framework doesn't intend to handle certain classes of request paths, it should probably respond with an appropriate 4xx code instead of just terminating the connection.
4. Real websites get tons of nonsense requests every day..the web server shouldn't be cluttering logs with huge exception trace like this every time.

IO split patch review

The IO split draft currently at 791a0e6d88dd51689a4f should be reviewed before we merge it into master. All major issues i encountered during my tests are fixed, and benchmarks show little to no performance degradation. Explanation for "little": the managed IO code didn't guarantee some things the libev IO code did guarantee, and as a consequence, http transaction and managed IO did not get along too well. That is fixed with a rather nasty workaround for time being.

Major points of the changeset:

• it is now possible to use the IO core of manos without having to link the http part
• we now have a compile-time flag that forces Manos.IO to the managed implementation, so the IO core is also embeddable into pretty much everything CLR
• multiple event loops, now named contexts, are possible without any imposed binding to threads
• factories for file streams and sockets per context, the resulting objects are then bound to that context and process events through it's event loop
• prepare, check, idle and async watchers per context for whatever you might want to do with them

any feedback is welcome.

Processing of further requests over a single connection hangs in certain situations.

I've noticed that sometimes refreshing my manos-served pages resulted in browsers waiting for the server to respond until timing out. As far as my testing revealed, it happens randomly on keep-alive connections when using non-chunked responses with SendFile, and consistently on the first connection of a newly started manos app after any non-chunked response is returned (even empty). It happens only when connecting locally, remote connections seem to be unaffected.
Tested on mono 2.8.2 and 2.10 on gentoo/amd64, with manos a3d19af.

Testcase:
Get ("/foo", ctx => { ctx.Response.Stream.Chunked = false; ctx.Response.End(); });

curl -s -v -H'Connection: keep-alive' http://127.0.0.1:8080/foo -o /dev/null http://127.0.0.1:8080/foo -o /dev/null http://127.0.0.1:8080/foo -o /dev/null

Output:
* About to connect() to 127.0.0.1 port 8080 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> GET /foo HTTP/1.1
> User-Agent: curl/7.21.2 (x86_64-pc-linux-gnu) libcurl/7.21.2 GnuTLS/2.6.5 zlib/1.2.3
> Host: 127.0.0.1:8080
> Accept: /
> Connection: keep-alive
>
< HTTP/1.1 200 OK
< Content-Length: 0
<
{ [data not shown]
* Connection #0 to host 127.0.0.1 left intact
* Re-using existing connection! (#0) with host 127.0.0.1
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> GET /foo HTTP/1.1
> User-Agent: curl/7.21.2 (x86_64-pc-linux-gnu) libcurl/7.21.2 GnuTLS/2.6.5 zlib/1.2.3
> Host: 127.0.0.1:8080
> Accept: /
> Connection: keep-alive
>
[hangs here] * Connection died, retrying a fresh connect

TimerWatchers not working under Windows

Seems TimerWatchers don't work under Windows. Issues found:

1. TimerWatcher.Start() is never called meaning the System.Threading.Timer never fires
2. System.Threading.Timer callbacks can be re-entrant
3. Multiple timer events can be queued causing single shot timers to fire multiple times.

Here's the fixes I made:

toptensoftware@3acdcc0

Debug from Monodevelop

Those of us who used to Visual Studio - would really love to see monodevelop debugging of the manos app

Can't access remote IP address

I have an application where user sessions are bound to their /16 subnet.

I'd like to use Manos for a part of the application, but I cannot validate sessions without the IP address of the user.

libev-4 not compiling on windows

Running off master.
Opened vs2010, no mono installed..

when trying to compile the c project i get:

Error 2 error C1083: Cannot open source file: '..\libev-4.00\ev.c': No such file or directory C:\Documents and Settings\Administrator\Desktop\jacksonh-manos-ee505a8\src\libev\c1 libev

Regards

Ged

Problem with uploading file using multipart/form-data

Using tag 0.1.3 I had no problem with uploading file, it could be accessed through Request.Files. With current tip same code gives me

System.ArgumentOutOfRangeException: Argument is out of range.
Parameter name: startIndex
  at System.String.Substring (Int32 startIndex) [0x00000] in <filename unknown>:0 
  at Manos.Http.HttpMultiPartFormDataHandler.ParseContentType (System.String str) [0x00000] in <filename unknown>:0 
  at Manos.Http.HttpMultiPartFormDataHandler.HandleHeader (Manos.Http.HttpEntity entity) [0x00000] in <filename unknown>:0 
  at Manos.Http.HttpMultiPartFormDataHandler.HandleData (Manos.Http.HttpEntity entity, Manos.IO.ByteBuffer data, Int32 pos, Int32 len) [0x00000] in <filename unknown>:0 

TempFileUploadedFile cannot be read

unlike InMemoryUploadedFile, TempFileUploadedFile does not make Contents ready for reading by application. InMemoryUploadedFile.Finish() moves Position to 0.

I locally added

stream = File.OpenRead (TempFile);

in TempFileUploadedFile.Finish() and my app got working again, but am not sure if it is safe to leave it open. Probably it should implement IDisposable at least.

With current version any parsing does not work

With git's tip version even hello world example raises an error:
Exception while parsing
System.ArgumentException: Can't move past end of buffer.

Workaround is to turn off byte number checking in Manos' stream, however that should not happen anyway.

Improvements to manostool

I've made some improvements to manostool.... mostly to support my Mvc framework, but I think generally useful:

1. Ability to specify a layout name for the init command eg:

   manostool --init MyProject --layout mvc

2. Replace $APPNAME in cshtml, sln, csproj and .user files

3. New replacement variable $MANOSDIR

4. Improved server command with ability to set document root: (useful when launching from Visual Studio)

   manostool --server --docroot c:/myfolder

5. Improved server command with ability to launch browser after starting server

   manostool --server --browse:/Home/Index

6. Improved build command to allow specifying additional referenced assemblies in the manos.config file

   [manos]
   ReferencedAssemblies=System.Core.dll Microsoft.CSharp.dll Manos.Mvc.dll

toptensoftware@b3a481b

mach-o, but wrong architecture

after a few months away from playing with manos i had a few issues getting it to run today. (latest repo on OS X 10.7)
After compiling and trying to run manos -docs i get:

System.TypeInitializationException: An exception was thrown by the type initializer for Manos.AppHost ---> System.TypeInitializationException: An exception was thrown by the type initializer for Manos.Threading.Boundary ---> System.DllNotFoundException: libmanos

A bit of investegation boiled to the following two issues:
...
Mono: DllImport error loading library 'dlopen(/usr/local/lib/manos/libmanos.0.dylib, 9): no suitable image found. Did find:
/usr/local/lib/manos/libmanos.0.dylib: mach-o, but wrong architecture
...
Mono: DllImport error loading library 'dlopen(/usr/local/lib/manos/libev.4.dylib, 9): no suitable image found. Did find:
/usr/local/lib/manos/libev.4.dylib: mach-o, but wrong architecture
...

Both libmanos.0.dylib and libev.d.dylib is x86_64 (that is not a universal binary). Are these two files supposed to be 32 bit, 64 bit or universal?

Can someone else on OS X confirm this issue?

Regards,
Johnny