inspired from valyala/fasthttp

Trying https://github.com/2vg/mofuw/blob/master/tests/helloworld/minimal.nim results in a crashing binary on

OS: Windows 10 x64
Nim version: 0.18.0
mingw64: gcc version 6.3.0 (x86_64-win32-seh-rev1, Built by MinGW-W64 project)

Starting program: C:\Users\test\Nim\main.exe
[New Thread 10824.0x15d4]
[New Thread 10824.0x2e98]
[New Thread 10824.0x61a4]
[New Thread 10824.0x652c]
[New Thread 10824.0x2584]
[New Thread 10824.0x6278]
[New Thread 10824.0x1e40]
[New Thread 10824.0x3290]
[New Thread 10824.0x6788]

gdb output:

Thread 7 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 10824.0x1e40]
0x0000000000498f16 in mpParseRequest_CEx7bTRFZ7rayEZvsoamWg (
req=0x5426478 "GET / HTTP/1.1\r\ncache-control: no-cache\r\nPostman-Token: e27731de-9a38-46ae-88b7-20faa3261002\r\nAuthorization: Basic R0xPQkFMUkVGVU5EXHMuTUZULlNoYXJlcG9pbnQuRDM6S2JEZUY0eXpWc016azZFcjU1S04=\r\nUser-Agent:"..., mhr=0x0) at C:/Users/test/.nimble/pkgs/mofuw-0.2.0/mofuw/mofuparser.nim:69
69 mhr.httpMethod = nil

Workaround: compile time buffer size inc.

Like nim c -r -d:bufSize:65535 mofuwapp.nim

i will measure performance soon.

this is headache.
when buffer size is small, i dont know best way.

currently develop new routing module based on radix tree.

  import mofuw

  var s = ""

  proc handler(ctx: MofuwCtx) {.async.} =
    let t = s

  newServeCtx(
    port = 8080,
    handler = handler
  ).serve()

creates a type mismatch error, normally I would expect that this compiles with only a warning.
Tested using Nim Compiler Version 0.18.1 [Windows: amd64]; Compiled at 2018-08-26.

regex ? best way ?
i cant found yet.

still work now

A handshake may not be executed sometimes

using accept4 for better performance.
accept4 can accept client with set some flag.
bad commit. ec07e0

app.nim

import mofuw
import strutils
import tables

proc mytest*(x:string):string=
result="hello " & x

type
appHandler* =ref object of RootObj
proctable* :Table[string,proc(x:string):string]

proc initProcTable* (this:appHandler):void {.inline.}=
this.proctable["mytest"]=mytest

proc call* (this:appHandler,ctx:MofuwCtx):void {.inline.}=
var webresult:string=this.proctable [ctx.body] ("world")
mofuwResp(HTTP200,"text/plain",webresult)

myServer.nim

import mofuw
import strutils
import app
let myapp=appHandler()
myapp.initProcTable()
routes:
post "/test":
myapp.call(ctx)

newServeCtx(
port=8080,
handler=mofuwHandler)
.serve()

compile error: type mismatch: got <port: int literal(8080), handler: proc (ctx: MofuwCtx): Future[system.void]{.locks: .}>
but expected one of:
proc newServeCtx(servername = "mofuw"; port: int;
handler, hookrequest, hookresponse: MofuwHandler = nil;
readBufferSize, writeBufferSize = 4096; maxBodySize = 1048576 * 5;
timeout = 3 * 1000; poolsize = 128; isSSL = false): ServeCtx

expression: newServeCtx(port = 8080, handler = mofuwHandler)

yay.
uv_fs_ummmmmm

sendfile ?

Techempower benchmark has not started properly.
I have to investigate the cause further.
However, I hope someone will report a bug.

Nim is last, this is sad: https://github.com/nanoant/WebFrameworkBenchmark

TCP_FASTOPEN reduces the time spent for establishing a connection.

I'm getting an error when trying to read file contents into mofuwResp:

        ... nim_cms.nim(23, 12) Error: type mismatch: got <port: int literal(8000), handler: proc (ctx: MofuwCtx): Future[system.void]{.locks: <unknown>.}>
        ... but expected one of:
        ... proc newServeCtx(servername = "mofuw"; port: int;
        ...                 handler, hookrequest, hookresponse: MofuwHandler = nil;
        ...                 readBufferSize, writeBufferSize = 4096; maxBodySize = 1048576 * 5;
        ...                 timeout = 30 * 1000; poolsize = 128; isSSL = false): ServeCtx
        ... expression: newServeCtx(port = 8000, handler = mofuwHandler)

nim_cms.nim

import os, asyncfile
import mofuw, templates
import "./theme" as Theme

var theme = Theme(
    defaultName: "default",
    extension: "html",
    directory: parentDir(currentSourcePath()) / "views"
)
theme.init()

routes:
  serve("public")

  get "/":
    var data = await theme.defaultTheme.readAll()
    mofuwResp(HTTP200, "text/html", data)
    # mofuwOK("Hello")


echo "Starting CMS Server"

newServeCtx(
  port = 8000,
  handler = mofuwHandler
).serve()

theme.nim

import os, asyncfile

type Theme* = ref object
    defaultName*, extension*, directory*: string
    defaultTheme*: AsyncFile
    

proc init*(this: Theme) =
    this.defaultTheme = openAsync(this.directory / (this.defaultName & "." & this.extension))

Is there something I'm doing wrong?

I tried mofuw to serve an ubuntu ISO around 2GB on a 512MB VPS. The process gets killed and I assume its because of the readAll function.
https://github.com/2vg/mofuw/blob/master/src/private/http.nim#L300

Here is a sample of using asynchttpserver that won't use up all the memory

import asynchttpserver, asyncdispatch, asyncnet, asyncfile, strutils, ospaths, strformat

var server = newAsyncHttpServer()
proc cb(req: Request) {.async.} =
  let pathToFile = "/Users/jivan/Downloads/somelargefile.zip"
  let fileName = pathToFile.split(PathSep)[^1]
  var file = openAsync(pathToFile, fmRead)
  await req.client.send("HTTP/1.1 200 OK\r\n")
  await req.client.send("Content-Length: " & $file.getFileSize() & "\r\n")
  await req.client.send("Content-Type: application/force-download\r\n")
  await req.client.send(fmt"""Content-Disposition: attachment; filename="{fileName}"""" & "\r\n\r\n")
  while true:
    let data = await read(file, 10000)
    if data.len == 0:
      break
    await req.client.send(data)

  req.client.close()
  file.close()

waitFor server.serve(Port(8080), cb)

I wonder if there could be an option on large file sizes >5MB to be streamed rather than read into memory.

ASC order

• WebSocket
• Logging
• SSL
• HTTP/2.0 (impl and parser)
• FastCGI

The new Tech Empower bench is out includes mofuw but perf is abysmal.

I wonder if they forgot to compile with release. https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

need ?

f*ck hash table. slowwwwwwwwww shit.

maybe, implements SIMD proc in mofuparser.

participate to techempower's benchmark

bad

Recommend to write set -ueo pipefail to top of setup.sh.

still develop

for login.

nim-asyncdispatch2

or,

will create a better Future and develop a new asynchronous module.

It may be said that this result is the most right result.

I perform it within a few days.

However, since implementation of Vector IO in Windows is troublesome, this implementation will be a long way to go ;)

I'm trying to compile a simple example in /tests/routing/

My File:

import mofuw

routes:
  get "/":
    mofuwOK("Hello, World!")

  get "/user/{id}":
    mofuwOK("Hello, " & ctx.params("id") & "!")

  post "/create":
    mofuwOK("created: " & ctx.body)

newServeCtx(
  port = 8080,
  handler = mofuwHandler
).serve()

An error shows up:

/home/flairfocus/.nimble/pkgs/mofuw-2.0.0/private/http.nim(31, 34) Error: type mismatch: got <nil> but expected 'string'

Nim Version

nim -v
Nim Compiler Version 0.18.1 [Linux: amd64]
Compiled at 2018-08-18
Copyright (c) 2006-2018 by Andreas Rumpf

active boot switches: -d:release

Thanks for your work on this!
When I tried your minimal example

import mofuw

proc handler(req: mofuwReq, res: mofuwRes) {.async.} =
  routes:
    get "/":
      mofuwResp(
        HTTP200,
        "text/plain",
        "Hello, World!"
      )

handler.mofuwRun() # default listening port: 8080

in release mode and debug mode on windows 10 and
Nim Compiler Version 0.18.0 [Windows: amd64]
I recognize that the memory grows with each call to http://127.0.0.1:8080/ (~80kb per 10 times pressing F5 in browser) and then stays at this size until I do next call. I have the feeling, when I do enough calls, the memory is filled completely.
Am I doing something wrong? Should I manually free the memory?

request from java-shit