UriComponentsBuilder should provide a way to remove the extension from the path [SPR-10272]

[spring-projects-issues]

Daniel Gredler opened SPR-10272 and commented

Spring supports using both "Accept" HTTP headers and extensions (e.g. .xml and .json) for content type negotiation. However, if the client uses extensions, any URLs built using the UriComponentsBuilder will contain the extension.

For example, if the client GETs this book:

http://foo.com/rest/books/6

and you want the server to return a list of the URLs for each of the pages in the book, e.g.

http://foo.com/rest/books/6/pages/1

then if the client is using extensions for content type negotiation you end up with the following URI:

http://foo.com/rest/books/6.json/pages/1

if you use the standard URI building code:

fromCurrentRequest().path("/pages/{id}").buildAndExpand(pageId).toString()

It should be possible to remove the extension if it's there (or just ignore the removal if there is no extension):

fromCurrentRequest().removeExtension().path("/pages/{id}").buildAndExpand(pageId).toString()

---

Affects: 3.2 GA

Referenced from: commits 5017855

[spring-projects-issues]

Rossen Stoyanchev commented

We could add some such option. One tricky part is that removing the extension may lead to unexpected side effects, e.g. with a path that contains a dot for other reasons "/user/foo@bar.org".

[spring-projects-issues]

Daniel Gredler commented

Good point.

Another thing to note is that maybe it's not a matter of removing the extension, but rather relocating it transparently. So e.g.

fromCurrentRequest().path("/pages/{id}").buildAndExpand(pageId).toString()

Would generate different URLs depending on whether or not the client is using extensions for content type negotiation:

Generate http://foo.com/rest/books/6/pages/1 if the original request was for http://foo.com/rest/books/6

Generate http://foo.com/rest/books/6/pages/1.json if the original request was for http://foo.com/rest/books/6.json

[spring-projects-issues]

Rossen Stoyanchev commented

I would hesitate to make this automatic because of cases where "." doesn't indicate an extension. Possibly have methods like trimFileExtension() and keepFileExtension(). The latter would have the effect of advancing the file extension to the end of the path when new path or path segments are appended.

[spring-projects-issues]

Rossen Stoyanchev commented

I've added a method to ServletUriComponentsBuilder to remove and return any path extension. This should support well the use case you described (i.e. starting with the current Servlet requestURI and building new links, possibly preserving the extension). There is a test case that shows this and also see the method's Javadoc for details.

Getting direct access to the extension and allowing you to re-insert also means you have more control, e.g. in case you want to apply a different extension (or remove it entirely.)