Why does alps (or profile) path in spring-data-rest return json body with non matching header Content-Type: text/html?

Question

Right now the default Content-Type of my spring-data-rest (spring-boot 1.4.3.RELEASE) provided controllers are application/hal+json which makes sense. If I use chrome I get application/hal+json for the root of my application for instance since chrome uses an Accept header of "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8". However, the /profile (formally /alps) URLs provide text/html even though the response body is json (making the Content-Type not match the body). If you specifically ask for only application/json then you get the correct response header.

Here is the incorrectly working case (returns text/html when the document/body returned is NOT text/html):

$ http --verbose "http://localhost:8080/v1/profile/eldEvents" "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"

GET /v1/profile/eldEvents HTTP/1.1
Accept:  text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: localhost:8080
User-Agent: HTTPie/0.9.2



HTTP/1.1 200 
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Location, X-Auth, Authorization
Access-Control-Allow-Methods: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Location
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: text/html;charset=UTF-8
Date: Fri, 03 Feb 2017 01:16:14 GMT
Expires: 0
Pragma: no-cache
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Transfer-Encoding: chunked
X-Application-Context: application
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

{
  "alps" : {
    "version" : "1.0",
    "descriptors" : [ {
      "id" : "eldEvent-representation",
      "href" : "http://localhost:8080/v1/profile/eldEvents",
      "descriptors" : [ {
        "name" : "sequenceId",
        "type" : "SEMANTIC"
      }, {
...

Cut out the rest of the response, you can see from above it is json data.

I believe the correct Content-Type for the above request should be something similar to "application/json".

Answer 1

If this is still relevant for you: I've solved this by manually overriding all requests against /profile/* with no content-type defined.

@Component
public class ProfileContentTypeFilter extends OncePerRequestFilter
{
    private static final AntPathMatcher matcher = new AntPathMatcher();

    @Override
    protected void doFilterInternal (HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
    throws ServletException, IOException
    {
        if (request.getContentType() == null && matcher.match("/profile/*", request.getRequestURI()))
        {
            // Override response content type for unspecified requests on profile endpoints
            response.setContentType(MediaType.APPLICATION_JSON_VALUE);
        }

        filterChain.doFilter(request, response);
    }
}