Closed ndrbrt closed 3 years ago
hi @ndrbrt, i'm a bit surprised how you got there. http verbs TRACE and OPTIONS are not explicitly supported. a quick test i did just ignored the def trace()
on a viewset. can you comment on how the view is constructed?
Ok, I kinda figured out the problem. I have some urls which map to a view called not_found
, which explicitly returns a 404 (I had to disable some urls from a package the brute force way).
Now, that view looks like this:
from rest_framework.decorators import api_view
from django.http import Http404
from .constants import HTTP_METHODS
@api_view(HTTP_METHODS)
def not_found(request, *args, **kwargs):
raise Http404
And those HTTP_METHODS
constant is:
"""
HTTP Methods list, as reported on
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods
"""
HTTP_METHODS = [
'GET',
'HEAD',
'POST',
'PUT',
'DELETE',
'CONNECT',
'OPTIONS',
'TRACE',
'PATCH'
]
As I expected, after commenting the unsupported methods, it starts working.
In the end, I should probably solve this by just rewrite that view as a class, but maybe this is an edge case that's worth covering?
Thank you in advance.
even though quite uncommon we should not run into these kind of issues but rather just ignore those endpoints.
that fix should do it.
can you check this works with new release 0.13.0
?
I just tested it out and can confirm it's now working with 0.13.0
.
Thank you!
According to https://swagger.io/specification/#path-item-object, all the http verbs are supported in the OpenAPI schema. Personally, i would really like to see the HEAD verb there.
OPTIONS
: not available as view method as it is handled like e.g. permission_classes
(DEFAULT_METADATA_CLASS
/SimpleMetadata
). This is so fringe that I won't invest time here due to the very limited benefit.
TRACE
: rejected by upstream https://github.com/encode/django-rest-framework/issues/4320#issuecomment-235856970
CONNECT
: not sure this even applies to DRF.
HEAD
: The only extra HTTP method that might make sense.
head()
method it gets routed to GET
.ModelViewSets
, since HEAD
is possible for both list
and retrieve
I came up with a test but since HEAD
handling is a little bit different from the rest, this is not a straightforward as it might sound. I will try something out, but I'm only able to invest a limited amount of time here.
Right: CONNECT
is probably only interesting to proxies.
What i am missing is the head method generated by openapi-generator, and i am wondering if the api spec would need to advertise that.
well that is another good but orthogonal question but I would guess it needs to be included in the schema. some targets to openapi-generator might generate it in any case but I wouldn't bet on it. It's certainly in the realm of possible.
from a schema perspective it makes sense to include it if desired, but as I mentioned DRF handles HEAD a bit different which makes this a non-trivial change to spectacular (given above requirements).
Let me add HEAD specifically as a wish in a new issue then. Thank you for considering it.
My environment:
I got the following error: