Undue 405 error with POST request

[johndoe46]

Describe the bug

Sanic gives a HTTP 405 on POST request while it should give a HTTP 200. Problem does not happen with previous Sanic versions.

Code snippet

Example app:

from sanic import Sanic
from sanic.response import text

app = Sanic("test")

@app.route("/test/", methods=["POST"])
def do_post(request):
    return text("from post")

@app.route("/test/<foo>", methods=["GET"])
def do_get(request, foo):
    return text(foo)

app.run()

Client test:

user/Downloads : python3
Python 3.9.4 (v3.9.4:1f2e3088f3, Apr  4 2021, 12:19:19) 
[Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from requests import get, post
>>> (post("http://localhost:8000/test/"), get("http://localhost:8000/test/ok"))

Result with Sanic 21.12.1:

(<Response [405]>, <Response [200]>)
Result with Sanic 20.12.3:

(<Response [200]>, <Response [200]>)

Expected behavior

Sanic should give an HTTP 200 to the POST request.

Environment (please complete the following information):

• OS: MacOS
• Version 12.1

Additional context

Complete server traces:

(oldsanic 20.12.3) user/Downloads : python app.py 
[2022-01-20 17:27:26 +0100] [76738] [INFO] Goin' Fast @ http://127.0.0.1:8000
[2022-01-20 17:27:26 +0100] [76738] [INFO] Starting worker [76738]
[2022-01-20 17:27:31 +0100] - (sanic.access)[INFO][127.0.0.1:64750]: GET http://localhost:8000/test/ok  200 2
[2022-01-20 17:27:32 +0100] - (sanic.access)[INFO][127.0.0.1:64752]: POST http://localhost:8000/test/  200 9



(newsanic 21.12.1) user/Downloads : python app.py 
[2022-01-20 17:26:17 +0100] [76690] [INFO] 
  ┌──────────────────────────────────────────────────────────────┐
  │                        Sanic v21.12.1                        │
  │              Goin' Fast @ http://127.0.0.1:8000              │
  ├───────────────────────┬──────────────────────────────────────┤
  │                       │     mode: production, single worker  │
  │     ▄███ █████ ██     │   server: sanic                      │
  │    ██                 │   python: 3.9.4                      │
  │     ▀███████ ███▄     │ platform: macOS-12.1-arm64-arm-64bit │
  │                 ██    │ packages: sanic-routing==0.7.2       │
  │    ████ ████████▀     │                                      │
  │                       │                                      │
  │ Build Fast. Run Fast. │                                      │
  └───────────────────────┴──────────────────────────────────────┘

[2022-01-20 17:26:17 +0100] [76690] [WARNING] Sanic is running in PRODUCTION mode. Consider using '--debug' or '--dev' while actively developing your application.
[2022-01-20 17:26:17 +0100] [76690] [INFO] Starting worker [76690]
[2022-01-20 17:26:23 +0100] - (sanic.access)[INFO][127.0.0.1:64723]: GET http://localhost:8000/test/ok  200 2
[2022-01-20 17:26:25 +0100] - (sanic.access)[INFO][127.0.0.1:64725]: POST http://localhost:8000/test/  405 757

[Tronic]

Try app = Sanic("test", strict_slashes=True)

[ahopkins]

https://sanic.dev/en/guide/basics/routing.html#strict-slashes

https://community.sanicframework.org/t/route-paths-how-do-they-work/825?u=ahopkins

[Tronic]

@ahopkins Could we change the default to True in 22.3? This confusion is becoming a FAQ.

[johndoe46]

Thanks for the tip and the detailed explanation.

This is unfortunate but reasonable. The "strict" behavior should be default IMO, as it's the least prone to confusion. As a matter of fact, should it be strict by default, my app wouldn't break as I'm pretty strict with trailing slashes myself, and I think this matter is best solved by redirections on NGinX side.

You may close this issue, thank you again for your help.

[ahopkins]

That does not seem sensible IMO. It would be a breaking change for a lot of applications. I would think that most people on the Internet would assume https://mysite.com/foo and https://mysite.com/foo/ to be the same thing. This is default in Sanic for as long as I can remember.

Since we corrected the bug in the old router, this is the 3rd time this has come up (I just went back to check). I would not call that frequent. I would call it a failure of the docs. We should fix that.

If we want to do anything, then maybe we discuss whether or not str matching includes and empty string "" (which it does and is the root of this "problem"). That (however) is a distinct issue from strict slashes.

@johndoe46 Here is a more thorough discussion: #2239 (comment)

And, it is also probably worth mentioning the alternative I gave there that <foo:alpha> will not have the empty string matching issues.