Actually the second link points to a post from you

There are lots of API endpoints which are not documented, mainly because the creator did not document them. (In this case I am at fault, though I doubt the endpoint I was replacing was documented either.)

So this is simply a bug. Using HttpResponses.forwardToPreviousPage() is commonplace in @RequirePOST endpoints that are not expected to display anything special where the UI invoker is just something that sends a POST via a form and does not want the rendered page to change. One easy fix would be to make this method in Stapler check whether there actually is a Referer, and if not, just delegate to ok() instead.

The proper fix would probably be to think of this as a real API and return 204 No Content, optionally with some body or status message indicating whether anything was actually canceled. It is also necessary to ensure that whatever status code is chosen, stopButton.jelly (called from two places with cancelItem) will not try to reload the page. From the use of onclick="new Ajax.Request(this.href); return false" it looks like this would already be true regardless of the status code.

And it looks like we need a Queue/_api.jelly listing the various operations. Currently this gives only generic information.

Alright, so it's actually a bug (although I maintain undocumented -> not really API).

Reducing priority as it's essentially cosmetic and can be ignored; maybe just disable following the bogus redirect.

Running into this bug as I am adding the feature to cancel a queue item to the jenkins-rest java library. I use Jenkins 2.107.1.

I also lost some time with this return code before seeing this issue, proposed some change to address this