Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-61308

REST Response Code to DeleteJob is a "302 - Found" redirect

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Fixed
    • core
    • Jenkins: CloudBees Jenkins Distribution 2.204.2.2-rolling
      OS: CentOS Linux 7 (Core)
    • Jenkins 2.227

    Description

      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) which results in receiving the full folder website. This behavior WOULD be appropriate when deleting via the web interface, but not a REST call.

      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. 

       

      EDIT: After some more research I discovered that some sites indeed use a "302" (or more appropriately "303 - See other") to point to the new resource. This still should not be the HTML page but instead the $JENKINS-URL/$PATh-TO-FOLDER/api/xml endpoint as this is a format that is easily parseable, unlike the HTML page.

      Attachments

        Issue Links

          Activity

            julian_schilling Julian Schilling created issue -
            julian_schilling Julian Schilling made changes -
            Field Original Value New Value
            Description 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:
            {quote}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.
            {quote}
            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. 
            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:
            {quote}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.
            {quote}
            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) which results in receiving the full folder website. This behavior WOULD be appropriate when deleting via the web interface, but not a REST call.

            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. 
            julian_schilling Julian Schilling made changes -
            Summary REST Response Code to DeleteJob is a 302 REST Response Code to DeleteJob is a "302 - Found" redirect
            julian_schilling Julian Schilling made changes -
            Description 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:
            {quote}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.
            {quote}
            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) which results in receiving the full folder website. This behavior WOULD be appropriate when deleting via the web interface, but not a REST call.

            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. 
            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:
            {quote}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.
            {quote}
            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) which results in receiving the full folder website. This behavior WOULD be appropriate when deleting via the web interface, but not a REST call.

            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. 

             

            EDIT: After some more research I discovered that some sites indeed use a "302" (or more appropriately "303 - See other") to point to the new resource. This still should not be the HTML page but instead the $JENKINS-URL/$PATh-TO-FOLDER/api/xml endpoint as this is a format that is easily parseable, unlike the HTML page.
            danielbeck Daniel Beck added a comment -

            When sending a POST to $JENKINS_URL/$PATH-TO-JOB/doDelete

            Please provide a reference to official documentation of this URL as an API. Otherwise this is just a browser action endpoint, and needs to behave in a way that works for browsers.

            danielbeck Daniel Beck added a comment - When sending a POST to $JENKINS_URL/$PATH-TO-JOB/doDelete Please provide a reference to official documentation of this URL as an API. Otherwise this is just a browser action endpoint, and needs to behave in a way that works for browsers.
            julian_schilling Julian Schilling added a comment - - edited

            Please provide a reference to official documentation of this URL as an API.

            On this site of the official wiki it states:

            For example, if your Jenkins installation sits at http://ci.jruby.org/, visiting http://ci.jruby.org/api/ will show just the top-level API features available – primarily a listing of the configured jobs for this Jenkins instance.

            When going to  $JENKINS_URL/$PATH-TO-JOB/api it says:

            To programmatically delete this job, do HTTP POST to this URL.

            Where "this URL" links to $JENKINS_URL/$PATH-TO-JOB/doDelete.
            Note that this is the ONLY thing stated there, nothing about what responses to expect or anything else.
            You can also perform a GET on that URL which will lead you to a page stating the following along with a button to perform a POST request:

            The URL you're trying to access requires that requests be sent using POST (like a form submission). The button below allows you to retry accessing this URL using POST. URL being accessed:

             

            I'm not sure if I understood you correctly in your comment, so please let me know if I misunderstood. My colleagues have the theory that there is another undocumented, "proper" API endpoint somewhere within Jenkins that is documented nowhere.

            julian_schilling Julian Schilling added a comment - - edited Please provide a reference to official documentation of this URL as an API. On this  site of the official wiki it states: For example, if your Jenkins installation sits at  http://ci.jruby.org/ , visiting  http://ci.jruby.org/api/  will show just the top-level API features available – primarily a listing of the configured jobs for this Jenkins instance. When going to  $JENKINS_URL/$PATH-TO-JOB/api it says: To programmatically delete this job, do HTTP POST to this URL. Where "this URL" links to $JENKINS_URL/$PATH-TO-JOB/doDelete. Note that this is the ONLY thing stated there, nothing about what responses to expect or anything else. You can also perform a GET on that URL which will lead you to a page stating the following along with a button to perform a POST request: The URL you're trying to access requires that requests be sent using POST (like a form submission). The button below allows you to retry accessing this URL using POST. URL being accessed:   I'm not sure if I understood you correctly in your comment, so please let me know if I misunderstood. My colleagues have the theory that there is another undocumented, "proper" API endpoint somewhere within Jenkins that is documented nowhere.
            danielbeck Daniel Beck added a comment -

            julian_schilling Thanks. I checked the API docs but must have missed this part. So this (tentatively) a real problem.

            danielbeck Daniel Beck added a comment - julian_schilling Thanks. I checked the API docs but must have missed this part. So this (tentatively) a real problem.
            danielbeck Daniel Beck added a comment -

            Interestingly, DELETE /job/whatever has the same weird behavior. That's probably the easier to fix one:

            1. Make DELETE behave correctly.
            2. Remove docs for doDelete, document this one instead.
            danielbeck Daniel Beck added a comment - Interestingly, DELETE /job/whatever has the same weird behavior. That's probably the easier to fix one: Make DELETE behave correctly. Remove docs for doDelete , document this one instead.
            danielbeck Daniel Beck made changes -
            Labels api api newbie-friendly
            danielbeck Daniel Beck made changes -
            Assignee Daniel Beck [ danielbeck ]
            danielbeck Daniel Beck made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            danielbeck Daniel Beck made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            danielbeck Daniel Beck made changes -
            Remote Link This issue links to "PR 4590 (Web Link)" [ 24739 ]
            danielbeck Daniel Beck made changes -
            Released As Jenkins 2.227
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Closed [ 6 ]

            People

              danielbeck Daniel Beck
              julian_schilling Julian Schilling
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: