-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Platform: All, OS: All
-
Powered by SuggestiMate
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
I just realized that my setup has a port number in it too.
The root URL is:
I'm not able to see this problem now, was probably fixed already. Reopen if you
still see this.
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.
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/
/
{build#}) in Hudson in your browser?
What project type(s) have you seen this in?
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.
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.
I tested with current hudson svn using https and nonstandard port in SJSWS7u3..
didn't see this problem.
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>
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.
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:
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?
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?
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/
/
{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 /.
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
Created an attachment (id=273)
How I can reproduce this problem with Hudson 1.219