• 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

          terrydye added a comment -

          Created an attachment (id=273)
          How I can reproduce this problem with Hudson 1.219

          terrydye added a comment - Created an attachment (id=273) How I can reproduce this problem with Hudson 1.219

          mmastrac added a comment -

          I just realized that my setup has a port number in it too.

          The root URL is:

          https://server:9090/hudson

          mmastrac added a comment - I just realized that my setup has a port number in it too. The root URL is: https://server:9090/hudson

          Alan Harder added a comment -

          I'm not able to see this problem now, was probably fixed already. Reopen if you
          still see this.

          Alan Harder added a comment - I'm not able to see this problem now, was probably fixed already. Reopen if you still see this.

          mmastrac added a comment -

          Reopening. Can still reproduce.

          Note that I'm using:

          • https:// as the external protocol
          • an external port number
          • mod-ajp to proxy tomcat behind apache.

          mmastrac added a comment - Reopening. Can still reproduce. Note that I'm using: https:// as the external protocol an external port number mod-ajp to proxy tomcat behind apache.

          Alan Harder added a comment -

          Someone else attached some steps that navigate in via the rss feed.. does that
          matter? Do you see the wrong links just navigating to the build page
          (/job/

          {name}

          /

          {build#}

          ) in Hudson in your browser?
          What project type(s) have you seen this in?

          Alan Harder added a comment - Someone else attached some steps that navigate in via the rss feed.. does that matter? Do you see the wrong links just navigating to the build page (/job/ {name} / {build#} ) in Hudson in your browser? What project type(s) have you seen this in?

          Alan Harder added a comment -

          I see this line in decompose() in hudson.Functions:

          String rest = reqUri.substring(f.getUrl().length());

          I think the "off by one" problem happens here.. so "rest" becomes

          {last-digit}

          /
          instead of just /. Perhaps the "s" in https is causing this? I have a
          non-default port, but plain http, and I don't see this.

          Alan Harder added a comment - I see this line in decompose() in hudson.Functions: String rest = reqUri.substring(f.getUrl().length()); I think the "off by one" problem happens here.. so "rest" becomes {last-digit} / instead of just /. Perhaps the "s" in https is causing this? I have a non-default port, but plain http, and I don't see this.

          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: