Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Jul 30, 2016 · 15 comments
Assignees
Labels
type: bug type: task

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Jul 30, 2016

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:

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 30, 2016

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 31, 2016

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 31, 2016

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 2, 2016

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 5, 2016

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 16, 2016

bitsofinfo commented

Is there a workaround in the meantime?

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 19, 2016

Oyku Gencay commented

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

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 20, 2016

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 20, 2016

Oyku Gencay commented

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

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 20, 2016

Oyku Gencay commented

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

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 20, 2016

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 22, 2016

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 22, 2016

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 7, 2017

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 19, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug type: task
Projects
None yet
Development

No branches or pull requests

2 participants