By rkarczewski on

I've been playing with REST API for a while and everything works fine but I have a question about DELETE verb for taxonomy terms. I configured GET, POST, PATCH and DELETE for /taxonomy/term/{term_id} using RestUI and GET, POST and PATCH works fine but DELETE always returns 403 Forbidden. I use admin account for basic auth for simplicity and development purposes only and I do generate proper token (the same method as for POST and PATCH). Does anybody tried/tested DELETE verb for taxonomy terms or is it disabled for some reasons and that's why it always returns 403? Node DELETE works fine.

⋅ Categories: Drupal 8.x

Comments

paranan1234’s picture

paranan1234 commented

Some proxies support only some of HTTP methods.
please try to use X-HTTP-Method-Override to overridePOST method.

aalaap’s picture

aalaap commented

In my case, the configuration of the Apache web server was set to disallow DELETE request. Adding this to the Drupal root .htaccess file did the trick:

<IfModule mod_headers.c>
Header always set Access-Control-Allow-Methods "POST, GET, PUT, PATCH, DELETE"
</IfModule>

<Limit GET POST PUT DELETE HEAD OPTIONS PATCH>
Order allow,deny
Allow from all
</Limit>

When I was getting the 403 error, I noticed that the error was plain HTML, in spite of specifying the Accept: application/hal+json. There was no error in Drupal's log either, so I checked the Apache log and found this..

AH01797: client denied by server configuration:

Gotcha!

prasannag’s picture

prasannag commented

I faced the same issue, when I checked the request by printing, The object has the controller ViewPageController::handle, where as in deleting nodes, the request goes through RequestHandler::handle which is from the REST module.

Keeping ViewPageController in mind, I checked the views page for taxonomy views and found the a page with the same url pattern /taxonomy/term/%. Just tried disabling this view and hit the API, and checked the request, which now calls the RequestHandler controller.

So finally the issue is with same url pattern provided in Views page and the REST API, As the url pattern is already registered in views, the api call doesn't work.

You can check this by printing request in AuthenticationSubscriber class.

Hope this this gives you the required information.