Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 860319 - POST to /consumers/.../entitlements fails when product has no pool
Summary: POST to /consumers/.../entitlements fails when product has no pool
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Subscription Management
Version: 6.0.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: Unspecified
Assignee: candlepin-bugs
QA Contact: Katello QA List
URL:
Whiteboard:
Depends On:
Blocks: 771481
TreeView+ depends on / blocked
 
Reported: 2012-09-25 15:09 UTC by Brad P. Crochet
Modified: 2014-01-27 13:26 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-10-11 19:23:15 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Brad P. Crochet 2012-09-25 15:09:04 UTC 
Description of problem:
Calling api of /consumers/<uuid>/entitlements, POST with no params, yields an empty body. It returns a status of 200 (which is not appropriate), and no body. This causes the Content-Type header to be 'json', instead of 'application/json', which can confuse some clients.

Version-Release number of selected component (if applicable):
# rpm -qa | grep candlepin
katello-candlepin-cert-key-pair-1.0-1.noarch
candlepin-selinux-0.7.8.2-1.el6.noarch
candlepin-0.7.8.2-1.el6.noarch
katello-glue-candlepin-1.1.12-1.git.76.e73b105.el6.noarch
candlepin-tomcat6-0.7.8.2-1.el6.noarch


How reproducible:
Always

Steps to Reproduce:
1. curl -k -E ./certificate.pem -X POST https://katellohost/katello/api/consumers/ffffffff-ffff-ffff-ffff-ffffffffffff/entitlements
2. This also happens if you call /candlepin/consumers/.../entitlements, with the change that the Content-Type is correct (application/json)
3.
  
Actual results:
Empty body, with incorrect response code and content-type header.

Expected results:
Error message stating attempt to subscribe to product with no pool

Additional info:
Comment 1 Brad P. Crochet 2012-09-25 15:10:17 UTC 
See: https://github.com/candlepin/candlepin/pull/72
Comment 3 Mike McCune 2012-10-10 14:30:45 UTC 
this is fixed upstream in Candlepin, CFSE will get it with 2.0
Comment 4 Devan Goodwin 2012-10-11 19:15:22 UTC 
Apologies guys, we missed some things in the patch review and we're going to have to pull this fix out. There are two issues, one in how that exception is being returned (clients expect a displayMessage in exceptions, we throw new BadRequestException to do this).

The second however is that the empty response is 100% expected behavior. This call is used for autobinds/healing where the client is essentially just saying "fix me if you can", and the server returns all the entitlements it granted to do this. An empty response indicates it wasn't able to grant any new entitlements.

The situation is complicated further by legacy clients that used to use the same call to bind to specific products. Changing the response from nothing to a 409 could be causing issues with legacy (i.e. 5.7) but still supported clients.

I do not know why you're getting a wonky content type but I don't think it's coming from candlepin, if I do this request against a straight candlepin server:

curl -v -k -u admin:admin -X POST "https://host:8443/candlepin/consumers/5708e217-2229-4da8-832d-ead20064a0a6/entitlements"

I get: Content-Type: application/json

So my questions are:

1: Could you investigate why that content type is mangled between Katello/Candlepin?

2: Can you live without this behaviour change from empty response to bad request? It doesn't look ideal in any case as it should be empty list but it looks like that has changed too. Regardless I'd like to keep it as 200 + empty response if autobind just couldn't figure out any improvements. We've gotta be super careful with changes here as we're supporting clients way way back.

Thanks!
Comment 5 Brad P. Crochet 2012-10-11 19:23:15 UTC 
Ok to revert. The change is likely way too risky for older clients.
Comment 6 Mike McCune 2013-08-16 18:12:37 UTC 
getting rid of 6.0.0 version since that doesn't exist
Note You need to log in before you can comment on or make changes to this bug.