Bug 866359

Summary: API: /consumers/{id}/entitlements returns incorrect data and Content-Type header
Product: Red Hat Satellite Reporter: Brad P. Crochet <brad>
Component: APIAssignee: Adam Price <adprice>
Status: CLOSED UPSTREAM QA Contact: Jitendra Yejare <jyejare>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.0.1CC: bkearney, ehelms, jomara, mmccune, tomckay
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 872602 (view as bug list) Environment:
Last Closed: 2013-09-19 18:13:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 872602    

Description Brad P. Crochet 2012-10-15 07:51:42 UTC
Description of problem:
Some API calls that are proxied to candlepin return an incorrect Content-Type header that can cause some clients to fail. Best known case is calling /consumers/{id}/entitlements, with no params. When this call results in no entitlements, the Content-Type returned is 'json', instead of the correct 'application/json'. Candlepin itself returns the correct header value when called directly. 

Version-Release number of selected component (if applicable):
katello-1.1.12-14.el6cf.noarch

How reproducible:
Always

Steps to Reproduce:
1. attempt to consume an entitlement calling /consumers/{id}/entitlements with no arguments.
2.
3.
  
Actual results:
Completely empty return, with a Content-Type header value of 'json'

Expected results:
Empty list ('[]') with Content-Type header value of 'application/json'

Additional info:

Comment 2 Tom McKay 2012-10-24 19:12:16 UTC
@adprice since you were messing w/ headers already, here's one to take a look at.

Comment 6 Mike McCune 2013-08-16 18:22:36 UTC
getting rid of 6.0.0 version since that doesn't exist

Comment 7 Mike McCune 2013-09-19 18:13:19 UTC
These bugs have been resolved in upstream projects for a period of months so I'm mass-closing them as CLOSED:UPSTREAM.  If this is a mistake feel free to re-open.