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.