404 response instead of 405 about teapot HOT 7 CLOSED

@gcotelli ok, I'll add an overridable not found handler (with a reference implementation for handling 405) so that the user can implement any custom logic there.

from teapot.

Thank you @zeroflag !

I loaded the latest version, configured Teapot to use the new handler and now all our test suite is passing. So it's seems to be working and not breaking other things!.

I will wait for the new release to change our dependencies.

from teapot.

Hi @gcotelli,

I've just released v2.6 as a new stable version.

Attila

from teapot.

hey @gcotelli,

I have some negative feelings regarding this. The RFC also says this:

The origin server MUST generate an
   Allow header field in a 405 response containing a list of the target
   resource's currently supported methods.

This would require adding more processing and complexity in Teapot and I don't think other similar frameworks care about this. I only checked sinatra but that one also returns 404 in this case.

require 'sinatra'
get '/hello' do
    'hi'
end

[root@c7401 vagrant]# curl -v -X OPTIONS http://localhost:4567/hello
* About to connect() to localhost port 4567 (#0)
*   Trying ::1...
* Connected to localhost (::1) port 4567 (#0)
> OPTIONS /hello HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:4567
> Accept: */*
> 
< HTTP/1.1 404 Not Found 

I'm not sure if this can be implemented in a efficient way considering that we also have regexp based routing and subrouters.

Do you know any other frameworks which implements this?

from teapot.

Hi @zeroflag !
Yes, you need to also provide the Allow Header with the supported methods for the resource.

As far as I know Spring-Boot (by using Spring) supports it. They seem to throw a MethodNotAllowedException when there's a mismatch, and later use it to generate the response. I barely know it but seems to implement the handling.

If you don't want to add this complexity by default, can at least refactor it in some way that allows for extension? So we can plug our own policy there and generate the expected error.

I suppose the changes in Teapot must be something like trying to match the different routes and when the route match but not the method keep this information somewhere, so at the end if none of the routes can handle the request, instead of returning always 404, return 405 and use the collected information to produce the header.

from teapot.

https://www.yiiframework.com/doc/guide/2.0/en/rest-error-handling Seems to support the 405 error code on invalid methods.

from teapot.

@gcotelli, I committed the change to smalltalkhub.

Name: Teapot-Core-AttilaMagyar.89
Author: AttilaMagyar
Time: 6 November 2018, 10:31:07.375037 pm
UUID: 3475dc74-6736-0d00-817c-f9510590a9ce
Ancestors: Teapot-Core-AttilaMagyar.88

404 response instead of 405 #4

Name: Teapot-Tests-AttilaMagyar.60
Author: AttilaMagyar
Time: 6 November 2018, 10:31:45.411527 pm
UUID: fdd82077-6736-0d00-817d-447e0590a9ce
Ancestors: Teapot-Tests-AttilaMagyar.59

404 response instead of 405 #4

Example:

teapot := Teapot configure: { #notFoundHandlerClass -> Tea405AwareNotFoundHandler }.
teapot 
	POST: '/a' -> 'post';
	PUT: '/a' -> 'put';
	start.

$ curl -v -X DELETE http://localhost:1701/a
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 1701 (#0)
> DELETE /a HTTP/1.1
> Host: localhost:1701
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 405 Method Not Allowed
< Allow: POST, PUT
< Content-Type: text/plain;charset=utf-8
< Server: Zinc HTTP Components 1.0 (Pharo/7.0)
< Content-Length: 30
< Date: Tue, 06 Nov 2018 21:34:32 GMT
< 
Method Not Allowed DELETE /a
* Connection #0 to host localhost left intact

Let me know if you face any issues.

from teapot.