REST calls to /api always redirect to HAL Browser if no accept header is specified [DATAREST-863]

[spring-projects-issues]

Kai Tödter opened DATAREST-863 and commented

After updating 2 projects to Spring Boot 1.4 (and Spring Data Rest 2.5.2) all REST calls to /api that don't specify a header like "accept: application/json" redirect to /api/browser/index.html#/api/. In previous versions this was only the case when the accept header was text/html, but now the redirect happens with empty accept header.

This may have nothing to do with Spring Data Rest directly, I just put it here because HAL Browser is involved.

But as a result, the default HAL browser itself cannot get the /api and shows its own index.html

---

Affects: 2.4.4 (Gosling SR4), 2.5.2 (Hopper SR2), 2.6 M1 (Ingalls)

Attachments:

• halbrowser.jpg (390.67 kB)

Issue Links:

• DATAREST-870 CustomAcceptHeaderHttpServletRequest doesn't work as intended with Spring Framework 4.3.2
  ("is duplicated by")

Referenced from: commits 344c3ac, 0cae0e5, 094bb99

Backported to: 2.5.3 (Hopper SR3), 2.4.5 (Gosling SR5)

0 votes, 5 watchers

[spring-projects-issues]

Kai Tödter commented

I investigated further. When I set the accept header to application/json ist works.
But still: HAL Browser does not work out of the box...

[spring-projects-issues]

Oliver Drotbohm commented

Actually I am suspecting a change in Spring 4.3 to cause that as we haven't changed our produces clauses. RepositoryController.listRepositories(…) is still bound to a GET request without a produces clause and HalBrowser.index(…) explicitly maps to text/html.

I'll bring that up with the Spring team but generally speaking, issuing a request without any Accept header is not guaranteed to return a particular representation. That the HAL browser does that by default is unfortunate. Adding the Accept header in the Custom Request Headers section of the browser

[spring-projects-issues]

Kai Tödter commented

Probably we could enhance the JavaScript code of the HAL browser that it always uses a proper accept header

[spring-projects-issues]

Oliver Drotbohm commented

I've identified the issue to be in a (didn't find out which one yet) Spring 4.3.2. In DelegatingHandlerMapping we consult the HandlerMapping instances for a matching handler. On Spring 4.3.1, the first one (which maps the browser, the JSON schema etc.) throws an exception as the direct path match, which is the method issuing the redirect to the browser, doesn't contain a matching produces clause. On 4.3.2 however, the handler lookup returns that method, although it doesn't actually match (we default the media type to application/hal+json) as apparently no matching media type check is done for direct path matches?. /cc Rossen Stoyanchev

[spring-projects-issues]

Oliver Drotbohm commented

It turned out the issue was caused by this commit to fix SPR-14506. It changed the way the ContentNegotiationStrategy looks up the Accept header in the request and the custom request wrapper that we put into place to default the header to a certain value not getting picked up anymore. That caused the mapping for the redirect to the HAL Browser to be picked up as it didn't cause any media type conflict anymore which would've triggered further handler mapping resolution.

That change basically flew under our radar as we didn't have any integration builds running against Spring Framework 4.3 (we're building against 4.2 currently). I've filed DATAREST-867 to keep track of that. Snapshots should be available as I write this. Feel free to give them a spin

[spring-projects-issues]

bitsofinfo commented

Is there a workaround in the meantime?

[spring-projects-issues]

Oyku Gencay commented

any workarounds except cloning and removing the / redirection from HalController?

[spring-projects-issues]

Oliver Drotbohm commented

The easiest workaround is to let clients specify an explicit accept header. The HAL Browser has a text field to add custom headers, so putting Accept: application/hal+json in there should do the trick

[spring-projects-issues]

Oyku Gencay commented

By "client" I suppose you mean the browser.?

[spring-projects-issues]

Oyku Gencay commented

BTW, you've mentioned a snapshot would be available. What's the version tag?
Thanks in advance

[spring-projects-issues]

Oliver Drotbohm commented

By client I mean client. Whoever uses your API.

That depends on how you're acutally using Spring Data REST. Boot? Standalone? The BOM? With Boot, set the spring-data-releasetrain.version property to either Ingalls-BUILD-SNAPSHOT, Hopper-BUILD-SNAPSHOT or Gosling-BUILD-SNAPSHOT. If you use the BOM, it's the same values but a slightly different mechanism

[spring-projects-issues]

Oyku Gencay commented

Thanks for the version explanation. Actually the problem I was trying to solve is the HAL Browser itself displaying HTML instead of the hal json content. See the screenshot attached. This happens with spring boot 1.4 and spring-boot-starter-data-rest and spring-data-rest-hal-browser as dependencies

Adding Accept: application/hal+json to custom headers does the trick but just wanted to point this out

[spring-projects-issues]

Oliver Drotbohm commented

I know, I know :). As described slightly more above, putting Accept: application/hal+json into the Custom Request Headers should to the trick until the fix is released

[spring-projects-issues]

Tim Schwalbe commented

Is this still not fixed? I have to apply "Accept: application/hal+json" to the custom request header. I am using:

	<parent>
	     <groupId>org.springframework.boot</groupId>
	    <artifactId>spring-boot-starter-parent</artifactId>
	    <version>1.4.0.RELEASE</version>
	</parent>
<dependencies>
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-data-rest</artifactId>
	</dependency>
	<dependency>
		<groupId>org.springframework.data</groupId>
		<artifactId>spring-data-rest-hal-browser</artifactId>
       </dependency>
</dependencies>

[spring-projects-issues]

Oliver Drotbohm commented

Boot 1.4.0 defaults to Hopper SR2. This one was fixed in SR3. So upgrading to the latest 1.4.x or even 1.5.x of Spring Boot should give you the fix