Red Hat Bugzilla – Bug 860319
POST to /consumers/.../entitlements fails when product has no pool
Last modified: 2014-01-27 08:26:39 EST
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:
See: https://github.com/candlepin/candlepin/pull/72
this is fixed upstream in Candlepin, CFSE will get it with 2.0
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!
Ok to revert. The change is likely way too risky for older clients.
getting rid of 6.0.0 version since that doesn't exist