| When sending a POST to $JENKINS_URL/$PATH-TO-JOB/doDelete Jenkins correctly deletes the Job and then responds with a response of "302 - Found". RFC 7231 describes this response as:
The 302 (Found) status code indicates that the target resource
resides temporarily under a different URI. Since the redirection
might be altered on occasion, the client ought to continue to use the
effective request URI for future requests.
The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY
use the Location field value for automatic redirection. The server's
response payload usually contains a short hypertext note with a
hyperlink to the different URI(s).
Note: For historical reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this
behavior is undesired, the 307 (Temporary Redirect) status code
can be used instead.
This doesn't seem like the appropriate response to a successful delete. The agent sends a POST (or GET) to the returned Location (from what I can tell the folder which contained the job, though this is documented nowhere). Instead, one would expect a "200 - OK" or "204 - No Content". Maybe a "203 - Accepted" if a deletion takes more time. As is, the returned status seems to make no sense as a 302 does not indicate success. Even worse, if the request was authenticated the 302 might lead to a place the user is forbidden to read! This results in the "Delete" request (indirectly) being answered with a "403 - Forbidden" or "404 - Not found", suggesting that the job that should be deleted wasn't found or that Jenkins refuses to honor the deletion request when it, in fact, has been accepted and fulfilled. At the very least this odd behaviour should be documented in the API documentation. Of course it would be preferable if it would actually be fixed. |
