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

404 on actions such as "Add build step" and "Add post-build action"

    • Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Minor Minor
    • core
    • None

      When the Jenkins application is started one may be unable to use actions such as "Add build step" and "Add post-build action" when on a job configuration page. Inspecting browser console, a 404 error can be observed, reading (Google Chrome):

      Failed to load resource: the server responded with a status of 404 (Not Found)
      

      The requested URL is:

      http://<jenkins.tld>:<port>/$stapler/bound/c5f8ba68-a3aa-4750-a824-dbc4db0aae0d/render
      

      From my observations, the issue is always stops reproducing after the Jenkins service is restarted.

      The behaviour has been observed with Jenkins versions 1.597, 1.601, 1.602. We haven't tested the versions in between. The issue does not seem to be dependent on the browser used, we've tested with latest Firefox and Google Chrome.

      The logs don't indicate an error.

      Request when the functionality is working (status code 200):

      Remote Address:<ip>:<port>
      Request URL:http://<domain>:<port>/$stapler/bound/944a638d-94cf-4eaa-b5b2-b3c25c9a536f/render
      Request Method:POST
      Status Code:200 OK
      Request Headersview source
      .crumb:732309a1f15b07f707c4f9db713b1b36
      Accept:text/javascript, text/html, application/xml, text/xml, */*
      Accept-Encoding:gzip, deflate
      Accept-Language:en-US,en;q=0.8
      Connection:keep-alive
      Content-Length:2
      Content-type:application/x-stapler-method-invocation;charset=UTF-8
      Cookie:ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE="aXZvOjE0MjY4NTU0NzA3Njk6OWIwYTM0NmY3ZDcwNzNhNWM4ZGU4NDJjMmRiNWFwZQ=="; screenResolution=1920x1080; JSESSIONID.fd92a8fb=4km5o289xgg31ioc1pe66bv26
      Crumb:732309a1f15b07f707c4f9db713b1b36
      Host:<domain>:<port>
      Origin:http://<domain>:<port>
      Referer:http://<domain>:<port>/job/bubefit/configure
      User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36
      X-Prototype-Version:1.7
      X-Requested-With:XMLHttpRequest
      Request Payloadview source
      []
      No Properties
      Response Headersview source
      Content-Encoding:gzip
      Content-Length:778
      Content-Type:text/html;charset=UTF-8
      Server:Jetty(winstone-2.8)
      

      Although I can't find any specific difference, I am adding below the requests that are being send in each situation (note I've collected those from separate machines, both running 1.602).

      Request when it is returning a 404:

      Remote Address:<ip>:<port>
      Request URL:http://<domain>:<port>/$stapler/bound/1ae868f4-612b-481a-b7a1-56b7017dc053/render
      Request Method:POST
      Status Code:404 Not Found
      Request Headersview source
      Accept:text/javascript, text/html, application/xml, text/xml, */*
      Accept-Encoding:gzip, deflate
      Accept-Language:en-US,en;q=0.8
      Connection:keep-alive
      Content-Length:2
      Content-type:application/x-stapler-method-invocation;charset=UTF-8
      Cookie:ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE="aXZheWxvLm1hcmlua292OjE0MjY4NTQ0MjM2MjU6OTgzZjFiMWJkM0YzE2Ng=="
      Crumb:abf7ffe4-4cf5-45d1-af58-f7a4197ef28a
      Host:<domain>:<port>
      Origin:http://<domain>:<port>
      Referer:http://<domain>:<port>/job/cloudhub-testing/configure
      User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36
      X-Prototype-Version:1.7
      X-Requested-With:XMLHttpRequest
      Request Payloadview source
      []
      No Properties
      Response Headersview source
      Cache-Control:must-revalidate,no-cache,no-store
      Content-Length:1423
      Content-Type:text/html;charset=ISO-8859-1
      Server:Jetty(winstone-2.8)
      

      I will be happy to provide any additional details you may think may be relevant to this issue.

          [JENKINS-27311] 404 on actions such as "Add build step" and "Add post-build action"

          Daniel Beck added a comment -

          Create a log recorder on level ALL for the logger org.kohsuke.stapler.bind.BoundObjectTable. Nothing in the log you uploaded appears to be relevant.

          Daniel Beck added a comment - Create a log recorder on level ALL for the logger org.kohsuke.stapler.bind.BoundObjectTable . Nothing in the log you uploaded appears to be relevant.

          The logger seems configured properly, yet I can't see anything different. Are you looking for anything specific?

          Ivaïlo Marinkov added a comment - The logger seems configured properly , yet I can't see anything different. Are you looking for anything specific?

          Daniel Beck added a comment -

          Please create a log recorder on level FINER for org.kohsuke.stapler.Stapler and repeat.

          Daniel Beck added a comment - Please create a log recorder on level FINER for org.kohsuke.stapler.Stapler and repeat.

          I created the logger and have attached the output to the Jira.

          Ivaïlo Marinkov added a comment - I created the logger and have attached the output to the Jira.

          Daniel Beck added a comment -

          If you know how to add headers to your requests using your browser's dev tools, run the following in Manage Jenkins » Script Console:

          org.kohsuke.stapler.Dispatcher.TRACE_PER_REQUEST = true

          And then add the header X-Stapler-Trace: true to your /$stapler/bound requests.

          Then, the log recorder for the logger org.kohsuke.stapler.Dispatcher will log things on FINE, and the 404 response should also contain some debug output.

          If you don't know how to add headers, run

          org.kohsuke.stapler.Dispatcher.TRACE = true

          to enable debug logging for all requests.

          These changes can be undone any time by running the equivalent ... = false script.

          Daniel Beck added a comment - If you know how to add headers to your requests using your browser's dev tools, run the following in Manage Jenkins » Script Console: org.kohsuke.stapler.Dispatcher.TRACE_PER_REQUEST = true And then add the header X-Stapler-Trace: true to your /$stapler/bound requests. Then, the log recorder for the logger org.kohsuke.stapler.Dispatcher will log things on FINE, and the 404 response should also contain some debug output. If you don't know how to add headers, run org.kohsuke.stapler.Dispatcher.TRACE = true to enable debug logging for all requests. These changes can be undone any time by running the equivalent ... = false script.

          I added the header and am attaching the contents of the log.

          I can see the response now contains two new headers,

          Stapler-Trace-001 -> evaluate(<org.kohsuke.stapler.bind.BoundObjectTable@1381a3c> :org.kohsuke.stapler.bind.BoundObjectTable,"/3dcbdb6b-087f-450b-988b-b6f97a7eb477/render")
          Stapler-Trace-002 -> evaluate(((StaplerFallback)<org.kohsuke.stapler.bind.BoundObjectTable@1381a3c>).getStaplerFallback(),"/3dcbdb6b-087f-450b-988b-b6f97a7eb477/render")

          Doesn't seem to give hints on the 404 though.

          Ivaïlo Marinkov added a comment - I added the header and am attaching the contents of the log. I can see the response now contains two new headers, Stapler-Trace-001 -> evaluate(<org.kohsuke.stapler.bind.BoundObjectTable@1381a3c> :org.kohsuke.stapler.bind.BoundObjectTable,"/3dcbdb6b-087f-450b-988b-b6f97a7eb477/render") Stapler-Trace-002 -> evaluate(((StaplerFallback)<org.kohsuke.stapler.bind.BoundObjectTable@1381a3c>).getStaplerFallback(),"/3dcbdb6b-087f-450b-988b-b6f97a7eb477/render") Doesn't seem to give hints on the 404 though.

          Debug information contained in the 404 response:

          404 Not Found
          
          Stapler processed this HTTP request as follows, but couldn't find the resource to consume the request
          
          -> evaluate(<org.kohsuke.stapler.bind.BoundObjectTable@1381a3c> :org.kohsuke.stapler.bind.BoundObjectTable,"/88d177f7-35c8-41a4-b65f-d07c8756cbd0/render")
          -> evaluate(((StaplerFallback)<org.kohsuke.stapler.bind.BoundObjectTable@1381a3c>).getStaplerFallback(),"/88d177f7-35c8-41a4-b65f-d07c8756cbd0/render")
          -> No matching rule was found on <org.kohsuke.stapler.bind.BoundObjectTable@1381a3c> for "/88d177f7-35c8-41a4-b65f-d07c8756cbd0/render"
          
          <org.kohsuke.stapler.bind.BoundObjectTable@1381a3c> has the following URL mappings, in the order of preference:
          
              TOKEN.groovy for url=/TOKEN
              VIEW.jelly for url=/VIEW
              org.kohsuke.stapler.bind.BoundObjectTable.PREFIX for url=/PREFIX/...
              org.kohsuke.stapler.bind.BoundObjectTable.DEBUG_LOGGING for url=/DEBUG_LOGGING/...
              org.kohsuke.stapler.bind.BoundObjectTable.getStaplerFallback() for url=/staplerFallback/...
              org.kohsuke.stapler.bind.BoundObjectTable.getStaplerFallback() for url=/staplerFallback/...
              org.kohsuke.stapler.bind.BoundObjectTable.getTable() for url=/table/...
              java.lang.Object.getClass() for url=/class/... 
          

          Ivaïlo Marinkov added a comment - Debug information contained in the 404 response: 404 Not Found Stapler processed this HTTP request as follows, but couldn't find the resource to consume the request -> evaluate(<org.kohsuke.stapler.bind.BoundObjectTable@1381a3c> :org.kohsuke.stapler.bind.BoundObjectTable, "/88d177f7-35c8-41a4-b65f-d07c8756cbd0/render" ) -> evaluate(((StaplerFallback)<org.kohsuke.stapler.bind.BoundObjectTable@1381a3c>).getStaplerFallback(), "/88d177f7-35c8-41a4-b65f-d07c8756cbd0/render" ) -> No matching rule was found on <org.kohsuke.stapler.bind.BoundObjectTable@1381a3c> for "/88d177f7-35c8-41a4-b65f-d07c8756cbd0/render" <org.kohsuke.stapler.bind.BoundObjectTable@1381a3c> has the following URL mappings, in the order of preference: TOKEN.groovy for url=/TOKEN VIEW.jelly for url=/VIEW org.kohsuke.stapler.bind.BoundObjectTable.PREFIX for url=/PREFIX/... org.kohsuke.stapler.bind.BoundObjectTable.DEBUG_LOGGING for url=/DEBUG_LOGGING/... org.kohsuke.stapler.bind.BoundObjectTable.getStaplerFallback() for url=/staplerFallback/... org.kohsuke.stapler.bind.BoundObjectTable.getStaplerFallback() for url=/staplerFallback/... org.kohsuke.stapler.bind.BoundObjectTable.getTable() for url=/table/... java.lang. Object .getClass() for url=/class/...

          Daniel Beck added a comment -

          According to the source code, the BoundObjectTable.Table is stored in the HttpSession.

          Since the broken request does not have a JSESSIONID, I'd try to find out why that is. This may be the culprit.

          Is Jenkins configured for the correct protocol, hostname, and port in the global config? Maybe there's even a reverse proxy config warning on the /manage page?

          Daniel Beck added a comment - According to the source code, the BoundObjectTable.Table is stored in the HttpSession. Since the broken request does not have a JSESSIONID, I'd try to find out why that is. This may be the culprit. Is Jenkins configured for the correct protocol, hostname, and port in the global config? Maybe there's even a reverse proxy config warning on the /manage page?

          Indeed, the instance showed such a warning. I reconfigured it so the warning text disappeared.

          The 404 would sometimes be present when a job configuration is opened using an URL that does not match the one specified in Jenkins URL on the Configure System page. For example, when the port is omitted.

          So far my observation is that it is always working when the exact URL specified is used, which should mean there is no actual issue.

          Thank you for your help!

          Ivaïlo Marinkov added a comment - Indeed, the instance showed such a warning. I reconfigured it so the warning text disappeared. The 404 would sometimes be present when a job configuration is opened using an URL that does not match the one specified in Jenkins URL on the Configure System page. For example, when the port is omitted. So far my observation is that it is always working when the exact URL specified is used, which should mean there is no actual issue. Thank you for your help!

          Daniel Beck added a comment -

          Resolving, Jenkins needs to be accessed using the exact URL configured in the global config.

          Daniel Beck added a comment - Resolving, Jenkins needs to be accessed using the exact URL configured in the global config.

            Unassigned Unassigned
            imarinkov Ivaïlo Marinkov
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: