[Nim] Add akane - Githubissues

waghanza commented 3 years ago

Hi @Ethosa,

Following https://github.com/Ethosa/akane/issues/1, this PR adds akane in here.

Thanks for your help :tada:

However, is there any way to :

send plain/text instead of json or html
avoid having <head><meta charset='utf-8'></head> while response.answer

Also, I have SIGSEGV: Illegal storage access. (Attempt to read from nil?) for routes /user/:id and /user

Regards,

Ethosa commented 3 years ago

I added the macros sendPlainText and send. https://github.com/Ethosa/akane/blob/master/tests/test8/main.nim what about the attempt to read from nil error, which version of Nim was used?

waghanza commented 3 years ago

I have Error: attempting to call undeclared routine: 'sendPlaintext' with a nimble file

# requires "akane >= 0.1.1 & < 0.2"
requires "https://github.com/Ethosa/akane.git"

Ethosa commented 3 years ago

The bug was fixed, the current version is 0.1.3 https://github.com/Ethosa/akane/releases/tag/v0.1.3

waghanza commented 3 years ago

It's OK for sendPlainText, but I still have SIGSEGV: Illegal storage access. for await request.sendPlainText(url[0])

I'm on nim 1.2.0

waghanza commented 3 years ago

and I have

could not load: libpcre.so(.3|.1|)
compile with -d:nimDebugDlOpen for more information

when try to launch on alpine

/cc @dom96

waghanza commented 3 years ago

@Ethosa seems that :

any POST method leads to a SIGSEGV: Illegal storage access. (Attempt to read from nil?)
sendPlainText leads to the above message, but I replace it with send

Ethosa commented 3 years ago

I didn’t understand where the Attempt to read from nil error came from. Everything works on Windows 7 x64. The error could not load: libpcre.so(.3|.1 |) on alpine occurred due to the fact that there, apparently, there was no PCRE library, on the basis of which the standard module was implemented re.

waghanza commented 3 years ago

Seems that I have this (SIGSEGV: Illegal storage access.) on all POST methods, either on linux or on osx

(Also folks have the same on nil discord channel)

I do not know why this not occurs on windows

PS : I'm using 1.2.0

Willyboar commented 3 years ago

@waghanza and @Ethosa this code works for me:

import akane

proc main {.gcsafe.} =
  let server = newServer("0.0.0.0", 3000)

  server.pages:
    "/": 
      if request.reqMethod == HttpGet:
        await request.send("")
      else:
        await request.error("not GET :(")

    "/user":
      if request.reqMethod == HttpPost:
        await request.send("")
      else:
        await request.error("not POST :(")

    regex(re"\A/user/(\d+)\Z"):
      if request.reqMethod == HttpGet:
        await request.send(url[0])
      else:
        await request.error("method not allowed")

    notfound:
      await request.error("not found")

  server.start()

main()

EDIT: Crashes if id is not an integer

EDIT2: I you change the regex with: regex(re"\A/user/(\w+)\Z"): will work for both integers and strings.

Checked with Postman on Mac OSX.

waghanza commented 3 years ago

I have always a SIGSEGV: Illegal storage access. (Attempt to read from nil?) on POST compile from master without options and into nimlang/nim:1.2.0

waghanza commented 3 years ago

@Ethosa @Willyboar specify a content-length -> curl http://0.0.0.0:3000/user -X POST -H 'Content-Length: 0' -v there is not issue

the issue seems to be in async dispatch, the full stack

   Success: Execution finished
Traceback (most recent call last)
/home/waghanza/workspace/benchmark/web/nim/akane/server.nim(30) server
/home/waghanza/workspace/benchmark/web/nim/akane/server.nim(28) main
/usr/share/nim/lib/pure/asyncdispatch.nim(1886) waitFor
/usr/share/nim/lib/pure/asyncdispatch.nim(1576) poll
/usr/share/nim/lib/pure/asyncdispatch.nim(1340) runOnce
/usr/share/nim/lib/pure/asyncdispatch.nim(210) processPendingCallbacks
/usr/share/nim/lib/pure/asyncmacro.nim(37) processRequestNimAsyncContinue
/usr/share/nim/lib/pure/asynchttpserver.nim(254) processRequestIter
/usr/share/nim/lib/pure/asynchttpserver.nim(103) respond
/usr/share/nim/lib/pure/httpcore.nim(180) hasKey
SIGSEGV: Illegal storage access. (Attempt to read from nil?)

leads me to thing this was in asynchttpserver.nim in stdlib

waghanza commented 3 years ago

:fire: :warning: we have to have for nim next release to merge it

waghanza commented 3 years ago

Merge is blocked by #2989

waghanza commented 3 years ago

We are almost done

2 issues :

alpine required libprce even if I Have install pcre-dev

/usr/src/app # ./server
could not load: libpcre.so(.3|.1|)
compile with -d:nimDebugDlOpen for more information

/cc @Willyboar @Ethosa

returning a 411 Content-Length required.

/cc @OvermindDL1 is the content-Length required ?

OvermindDL1 commented 3 years ago

is the content-Length required ?

Depends on a few factors such as the call type and the http version, but for, say, GET requests it's (basically) always required unless you are sending the data chunked, or else the client wouldn't know when the body would stop.

waghanza commented 3 years ago

Thanks @OvermindDL1 🎉 In fact the question is more for POST, akane is the only framework** that return a 411 on POST (we are the default http version, I think 1.1)

OvermindDL1 commented 3 years ago

POST is also a call type that returns a body, so it should have a content-length as well or be a chunked response.

waghanza commented 3 years ago

Ah yes of course. It should have a Content-Length in the response :ok_hand:

However, with akane a request curl -v http://0.0.0.0:3000/user -X POST return a 411 (specifying the Content-Length header fix this)

OvermindDL1 commented 3 years ago

Personally sounds like either a bug in akane that's not filling it in automatically based on the body length, or it should be documented that it must be user supplied?

waghanza commented 3 years ago

I also find this weird @OvermindDL1, let's wait for @Ethosa

waghanza commented 3 years ago

solved with https://forum.nim-lang.org/t/2236#14054

I understand this could fix could not load: libpcre.so(.3|.1|) on alpine, but I don't understand how it could impact the Content-Length issue

Ethosa commented 3 years ago

Ah yes of course. It should have a Content-Length in the response

However, with akane a request curl -v http://0.0.0.0:3000/user -X POST return a 411 (specifying the Content-Length header fix this)

I updated akane to version 0.1.5 and added a release, maybe now everything will work. :eyes:

Personally sounds like either a bug in akane that's not filling it in automatically based on the body length, or it should be documented that it must be user supplied?

Also documented the macros sendJson, send, error, answer and sendPlainText.

the-benchmarker / web-frameworks

[Nim] Add akane #2857