Reactive response URL-rewriting mechanism [SPR-14529]

[spring-projects-issues]

Daniel Fernández opened SPR-14529 and commented

Spring MVC-based applications make quite a lot of use of the URL-rewriting mechanism available at HttpServletResponse#encodeUrl(). This is normally done in a transparent way by the template engine.

This URL-rewriting mechanism allows the usage of several resource-management-oriented techniques, as well as of course setting URL-based session ids like ;jsessionid=x in case browser cookies are disabled.

I cannot find anything similar to this in ServerHttpResponse, so I suppose this is something not implemented yet. And probably not to be until a later milestone, but I need it for Thymeleaf's new Spring Reactive-specific link builder (in charge of building @{...} expressions), so I would like to keep track of when this gets implemented :)

---

Affects: 5.0 M1

Issue Links:

• Consider moving ServerHttpResponse encodeUrl / registerUrlEncoder to ServerWebExchange? [SPR-15924] #20478 Consider moving ServerHttpResponse encodeUrl / registerUrlEncoder to ServerWebExchange?
• Create ResourceUrlEncodingFilter for the reactive module [SPR-15012] #19579 Create ResourceUrlEncodingFilter for the reactive module
• Reactive HTTP response based RedirectView [SPR-14534] #19103 Reactive HTTP response based RedirectView
• Provide a RequestDataValueProcessor (or equivalent) mechanism in Spring Web Reactive [SPR-15001] #19568 Provide a RequestDataValueProcessor (or equivalent) mechanism in Spring Web Reactive

Referenced from: commits 7193686

[spring-projects-issues]

Rossen Stoyanchev commented

Daniel Fernández, just wondering if you would also prefer a registration mechanism for encodeUrl candidates in addition to the encodeUrl() method. As an alternative to wrapping the response.

[spring-projects-issues]

Daniel Fernández commented

Hmm... with "encodeUrl candidates" do you mean a way to know explicitly whether a URL should be encoded or not?

If that's it, I don't think the view layer would need that, or at least I cannot think right now of a use in which the view layer would need that. Note that the template engine is is just a user of the encodeUrl() mechanism and would not be a registerer of URL-encoding mechanisms, nor of encoding-candidate URLs.

IMHO the template engine should just call response.encodeUrl(url) on every URL, and the mechanisms underneath would be the ones in charge of transparently determining if a URL should or should not be encoded, and how.

If what you mean –I might be not understanding correctly– is to offer a way to determine whether encodeUrl() should be called or not beforehand… I think that would just add unneeded complexity, and give the template engine a responsibility I think it shouldn't have.

[spring-projects-issues]

Rossen Stoyanchev commented

Sorry for being unclear. I did not mean a mechanism for deciding which URLs to encode. I was simply suggesting an explicit registration with the response of some API type that has an encodUrl method. As an alternative to having to wrap the response in order to override its encodeUrl method. In other words if the goal is to provide a pluggable mechanism to encode the URL why don't we make it explicit vs relying on wrapping?

[spring-projects-issues]

Rossen Stoyanchev commented

Also note there are other similar cases for example to associate a Principle with the request. It could be said that applications will typically not need to see or use methods such as the registration of an encodeUrl function, nor to configure the user for the request, and so on. So it is cleaner if such methods don't appear in the request and response.

There is also a case to be made to keep the read-only nature of a request. On the other hand anyone can create a WebFilter to wrap the request or the response or both, both before and after the target WebHandler is invoked, so in the end I don't see much value in making this harder than it needs to be.

Perhaps a good compromise would be to create separate interfaces for a "configurable" request and response as extensions of the request and response. We could pass those into the WebFilter, or provide a method on the request and response that returns the "configurable" interface, or simply leave it to checking and downcasting the request and response to the "configurable" extension. Any of those would keep these methods separate from the main API.

[spring-projects-issues]

Daniel Fernández commented

Okay, now I understand. Thanks for the explanations.

Strictly from the standpoint of a view-layer template engine like Thymeleaf, these kind of mechanisms are transparent. As long as when response.encodeUrl(...) is called all registered/wrapped URL-encoding methods are adequately applied and aggregated, the view layer will be happily able to rewrite the URLs being output without noticing the specifics of the implementation.

I see both the good and the bad points in the possibilities you describe, though IMHO the configurable interface part looks like a bit too much complexity to me. In such case, I would be worried about how the easiness of wrapping the response would suffer — if I still want to do that for whatever reason. Maybe providing a sensible default wrapping class for the response –something I could easily extend if I want to create a wrapper– would be good enough?

[spring-projects-issues]

Rossen Stoyanchev commented

I don't think what I'm suggesting gets in the way of wrapping the response or makes it any more or less complex, does it? It should be rather neutral in that regard. What I am proposing is reducing the need to wrap the request or response, which seems like a roundabout way to do something that is fully expected and arguably should be explicitly supported in the API.

[spring-projects-issues]

Daniel Fernández commented

Reducing the need of wrapping the response by providing an easier alternative sounds nice, of course. I was thinking that some people would still prefer to wrap the response because of being used to it coming from the ServletAPI world, and also for the sake of integration easiness — thinking of already existing libraries for URL rewriting –or even other purposes such as authentication/authorization–, developed by means of wrapping HttpFilter, which perhaps could be more easily adapted to Spring Reactive by wrapping WebFilter than by changing their base concept and switching to registering their encoding mechanisms somehow at the response. Anyway, not that this change would be a big deal I suppose.

As for the increase in complexity when wrapping, you are right, it shouldn't add complexity. I was thinking of the scenario you mentioned in which ServerHttpResponse has a method returning a ConfigurableServerHttpResponse or something like that. But somehow I wasn't realising that what would be returned by that getConfigurableServerHttpResponse() would actually be (ConfigurableServerHttpResponse)this. So in this case a wrapper would be done directly on the configurable interface and everything should be OK.

[spring-projects-issues]

Rossen Stoyanchev commented

Okay still thinking this over and will just have to try a few things out. I'll comment once I have something new. Feel free to comment with any further thoughts.

[spring-projects-issues]

Rossen Stoyanchev commented

There is now an encodeUri method on ServerHttpResponse.

[spring-projects-issues]

Daniel Fernández commented

Thanks so much. Applied to Thymeleaf's link builder for Spring Web Reactive already!