Bug 712448 - Error message displays wrong hostname and port
Error message displays wrong hostname and port
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: subscription-manager (Show other bugs)
6.2
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Chris Duryee
J.C. Molet
:
Depends On:
Blocks: rhsm-rhel62
  Show dependency treegraph
 
Reported: 2011-06-10 12:26 EDT by J.C. Molet
Modified: 2011-09-20 16:23 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-09-20 16:23:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
wrong hostname (24.10 KB, image/png)
2011-06-10 12:26 EDT, J.C. Molet
no flags Details

  None (edit)
Description J.C. Molet 2011-06-10 12:26:34 EDT
Created attachment 504154 [details]
wrong hostname

Description of problem:
When displaying an error message that shows the path of the candlepin server, the error message displays the proxy hostname and port instead of the candlepin hostname and port

Version-Release number of selected component (if applicable):
subscription-manager-gnome-0.96.1-1.git.213.27a76c6.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1.  Install rhsm off of master branch
2.  Build an older candlepin (I used 0.3 branch)
3.  Configure rhsm to use a proxy
4.  Register rhsm to that candlepin
5.  Try to search for subscriptions
  
Actual results:
You get the following error message:
Unable to search for subscriptions: Runtime Error Could not find resource for relative : /consumers/d189e56e-c205-4325-a7fb-b42b7081f438/owner of full path: https://auto-services.usersys.redhat.com:3129/candlepin/consumers/d189e56e-c205-4325-a7fb-b42b7081f438/owner at org.jboss.resteasy.core.registry.PathParamSegment.matchPattern:200

The error message shows that the hostname of the candlepin server is the proxy server.  For debugging purposes, wouldn't this error be clearer if it used the candlepin hostname?

Expected results:
The error would be something like this, using the candlepin hostname:

Unable to search for subscriptions: Runtime Error Could not find resource for relative : /consumers/d189e56e-c205-4325-a7fb-b42b7081f438/owner of full path: https://candlepin-server.usersys.redhat.com:8443/candlepin/consumers/d189e56e-c205-4325-a7fb-b42b7081f438/owner at org.jboss.resteasy.core.registry.PathParamSegment.matchPattern:200

Additional info:
Comment 1 Chris Duryee 2011-08-15 16:56:41 EDT
This error is coming from RESTEasy, via request.getUri().getRequestUri().

Can you post your squid settings? I think squid may be doing something to the HTTP headers.
Comment 5 Chris Duryee 2011-09-20 16:23:20 EDT
JC,

I was able to reproduce this with candlepin 0.3, but not 0.4 (even when hacking python-rhsm to reproduce the same error). In candlepin 0.3, this error was handled as a 500 ISE, but it is already corrected in 0.4 to be a regular 404. This is handled by python-rhsm to display a regular "Remote server error" box.

The root cause is that resteasy uses calls that appear to get data from getServerName instead of getLocalName. This is by design, but works against us in our particular use case (see http://tomcat.apache.org/tomcat-5.5-doc/proxy-howto.html#Introduction for more detail). These errors are correctly wrapped as a 404 in 0.4, so the user doesn't see the candlepin error message in the error box.

Since this only affects subscription-manager when using the older candlepin which is not in hosted production anymore, I'm going to set this as WONTFIX. Fixing it in subscription-manager is possible, but not worth the risk IMO, especially since it's already fixed in candlepin and the bug is low-impact. I did, however, add additional logging to candlepin to display getLocalName on requests in addition to getServerName.

Let me know if you disagree and we can discuss further.

Note You need to log in before you can comment on or make changes to this bug.