• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • other
    • None
    • Platform: All, OS: All

      The previous/next buttons for builds have incorrect build numbers:

      ie, for this build:

      https://****/hudson/job/****/637/

      The previous build is listed as:

      https://****/hudson/job/****/6367/

      It looks like an off-by-one error.

          [JENKINS-1457] Previous/Next buttons have incorrect URLs

          Alan Harder added a comment -

          Also please confirm what Hudson version you are using; please make sure to test
          this on 1.268 so I'm not looking for something that is fixed.. thanks.

          Alan Harder added a comment - Also please confirm what Hudson version you are using; please make sure to test this on 1.268 so I'm not looking for something that is fixed.. thanks.

          Alan Harder added a comment -

          I tested with current hudson svn using https and nonstandard port in SJSWS7u3..
          didn't see this problem.

          Alan Harder added a comment - I tested with current hudson svn using https and nonstandard port in SJSWS7u3.. didn't see this problem.

          mmastrac added a comment -

          Updated to v1.268, confirming bug still exists.

          One other thing I neglected to mention (probably not important) is that I'm
          using htaccess as well. I doubt this is the cause - I'm sure it's somewhere in
          the url parsing code.

          When I last looked into it, it turned out to be somewhere in the Stapler lib, I
          think. This was a while ago, however, and I can't remember where it was.

          This httpd conf should reproduce it. Save as hudson.conf in /etc/httpd/conf.d
          and restart httpd. Hit https://servername:9441/hudson.

          Listen 9441

          <VirtualHost *:9441>
          SSLEngine On
          SSLCertificateFile /etc/pki/tls/certs/localhost.crt
          SSLCertificateKeyFile /etc/pki/tls/private/localhost.key

          ProxyPass /hudson ajp://localhost:8009/hudson/

          <Location />
          Allow from all
          Order deny,allow
          AuthType Basic
          AuthName Auth
          AuthUserFile /.htpasswd
          Require valid-user
          </Location>
          </VirtualHost>

          mmastrac added a comment - Updated to v1.268, confirming bug still exists. One other thing I neglected to mention (probably not important) is that I'm using htaccess as well. I doubt this is the cause - I'm sure it's somewhere in the url parsing code. When I last looked into it, it turned out to be somewhere in the Stapler lib, I think. This was a while ago, however, and I can't remember where it was. This httpd conf should reproduce it. Save as hudson.conf in /etc/httpd/conf.d and restart httpd. Hit https://servername:9441/hudson . Listen 9441 <VirtualHost *:9441> SSLEngine On SSLCertificateFile /etc/pki/tls/certs/localhost.crt SSLCertificateKeyFile /etc/pki/tls/private/localhost.key ProxyPass /hudson ajp://localhost:8009/hudson/ <Location /> Allow from all Order deny,allow AuthType Basic AuthName Auth AuthUserFile /.htpasswd Require valid-user </Location> </VirtualHost>

          mmastrac added a comment -

          You know, I think it might be mod_ajp that causes the trouble. Unfortunately I
          need it to correctly pass the hostname to Hudson (Hudson doesn't work properly
          behind a standard HTTP proxy).

          I added an alternate http section:

          <VirtualHost *:80>
          ProxyPass /hudson ajp://localhost:8009/hudson/
          </VirtualHost>

          This causes the same error as with SSL. I guess the https/port numbers are red
          herrings.

          mmastrac added a comment - You know, I think it might be mod_ajp that causes the trouble. Unfortunately I need it to correctly pass the hostname to Hudson (Hudson doesn't work properly behind a standard HTTP proxy). I added an alternate http section: <VirtualHost *:80> ProxyPass /hudson ajp://localhost:8009/hudson/ </VirtualHost> This causes the same error as with SSL. I guess the https/port numbers are red herrings.

          mmastrac added a comment -

          OK - I figured it out, here's the bug:

          • The ProxyPass directive has an extra slash at the end, so it is sending an
            extra slash in the URL to the Tomcat server:

          ProxyPass /hudson ajp://localhost:8009/hudson/

          should be

          ProxyPass /hudson ajp://localhost:8009/hudson

          • When Hudson tries to view a project page with two slashes after the hudson
            root, it fails to strip the URL properly:

          http://servername/hudson//job/jobname/2477/

          but it works just fine with:

          http://servername/hudson/job/jobname/2477/

          mmastrac added a comment - OK - I figured it out, here's the bug: The ProxyPass directive has an extra slash at the end, so it is sending an extra slash in the URL to the Tomcat server: ProxyPass /hudson ajp://localhost:8009/hudson/ should be ProxyPass /hudson ajp://localhost:8009/hudson When Hudson tries to view a project page with two slashes after the hudson root, it fails to strip the URL properly: http://servername/hudson//job/jobname/2477/ but it works just fine with: http://servername/hudson/job/jobname/2477/

          Alan Harder added a comment -

          Nice work! So, this was a configuration issue that caused a very cryptic
          problem in Hudson.. should we just close this issue, or do you think Hudson
          could/should catch this somehow?

          Alan Harder added a comment - Nice work! So, this was a configuration issue that caused a very cryptic problem in Hudson.. should we just close this issue, or do you think Hudson could/should catch this somehow?

          mmastrac added a comment -

          I think this is a bit of a gotcha for those configuring Hudson behind a proxy
          like myself.

          I think a fix for the root cause is ideal, but detecting double-slashes on the
          configuration page (like it does for Tomcat's UTF8 encoding issues) would be
          sufficient as a warning. The symptoms only seem to manifest in a few places
          (generally parts that rewrite the current URL), so it's tough to figure out that
          there's a config issue vs. a bug in Hudson itself.

          Is the root issue for this bug in Hudson or in the Stapler project?

          mmastrac added a comment - I think this is a bit of a gotcha for those configuring Hudson behind a proxy like myself. I think a fix for the root cause is ideal, but detecting double-slashes on the configuration page (like it does for Tomcat's UTF8 encoding issues) would be sufficient as a warning. The symptoms only seem to manifest in a few places (generally parts that rewrite the current URL), so it's tough to figure out that there's a config issue vs. a bug in Hudson itself. Is the root issue for this bug in Hudson or in the Stapler project?

          Alan Harder added a comment -

          The root issue is in Hudson itself... that line of code I referenced above is
          making the assumption that the URI of this actual request will match the
          structure of an internally constructed string (webapp context root like
          "/hudson" plus some known path elements like "/job/

          {jobname}

          /

          {buildnumber}

          ").
          In this case the assumption is incorrect, since the request URI has an extra /
          but it was still a syntax that allowed handling to reach the right code....

          I don't have any proxy setup, but I can manually trigger this bug just by
          requesting a build URL with an extra /.

          Alan Harder added a comment - The root issue is in Hudson itself... that line of code I referenced above is making the assumption that the URI of this actual request will match the structure of an internally constructed string (webapp context root like "/hudson" plus some known path elements like "/job/ {jobname} / {buildnumber} "). In this case the assumption is incorrect, since the request URI has an extra / but it was still a syntax that allowed handling to reach the right code.... I don't have any proxy setup, but I can manually trigger this bug just by requesting a build URL with an extra /.

          Alan Harder added a comment -

          I like your idea of a warning on the manage page... but, I took another look at
          the Functions.decompose() code and I think I can update that logic to gracefully
          handle extra slashes.

          Alan Harder added a comment - I like your idea of a warning on the manage page... but, I took another look at the Functions.decompose() code and I think I can update that logic to gracefully handle extra slashes.

          Code changed in hudson
          User: : mindless
          Path:
          trunk/hudson/main/core/src/main/java/hudson/Functions.java
          http://fisheye4.cenqua.com/changelog/hudson/?cs=14174
          Log:
          [FIXED JENKINS-1457] Update logic in Functions.decompose to be immune to mismatches
          due to url-encoding or extra slashes in the request URL

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/hudson/main/core/src/main/java/hudson/Functions.java http://fisheye4.cenqua.com/changelog/hudson/?cs=14174 Log: [FIXED JENKINS-1457] Update logic in Functions.decompose to be immune to mismatches due to url-encoding or extra slashes in the request URL

            mindless Alan Harder
            mmastrac mmastrac
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: