Hi Jason, On Tue, 2018-09-11 at 13:23 -0400, Jason E Bailey wrote: > My concerns for a solution on this are: > > 1. I don't want the post dictating the service. > 2. There are times that I want to have a different servlet handle a > call. > > If this goes into effect where a POST says I must be handled by 'X' > my concern is where I'm building upon a downstream Application and I > *want* the POST to be handled by something else.
Is this about SLING-6767 - Jackrabbit Usermanager: Allow to detect whether a POST request was treated by the default POST servlet or the jackrabbit.usermanager [1]? If it is, let me paste the initial description here and the proposed solution: Description: Currently it is impossible to tell from the response whether a POST request has been answered by either the Default Sling POST servlet or the Jackrabbit Usermanager. Both the JSON and the HTML look exactly the same no matter, who answered. It should be possible to see from the client-side whether a request has been treated by one or the other. (My note): more generally, there are situations where a script/servlet is not available, such as: - startup - bundle restart - bundle missing We want to avoid mostly POSTing to an endpoint and having an incorrect result - whether it's creating a node or starting up processing. Proposed solution: To sum up the main points: - the problems appear when the servlet/script that handles the request is not the precise one that the client intended - usually the problems are caused by the Sling Default POST Servlet, but not always - a less intrusive solution would be to allow the client to say that it requires "precise" script resolution and reject the possibility of it being served by a less specific handler - for requests accessing existing resources, the resource type is known from the repository - for requests creating resources, the resource type is known from the request (although this might be non-generic, TBD) The proposed solution is to allow the client to set an HTTP header which specifies the type of resolution to use (provisional names): - default ( what we have today ) - precise ( the script/servlet must exactly match the resource type ) - relaxed ( what we have today, excluding the default resource type ) We discussed adding a request parameter but were not convinced that it is necessary, since now it's possible to add headers to requests in all relevant scenarios ( programatically, browser requests, developer tools ) and we can always add it later. Removing it after a release would be more problematic. -------- About your concerns, let me make sure I got them right > 1. I don't want the post dictating the service. The obvious question is why :-) . The alternative it to have the server dictate the service, but the question is how to do this is a way that is manageable and scaleable. > 2. There are times that I want to have a different servlet handle a call. > > If this goes into effect where a POST says I must be handled by 'X' > my concern is where I'm building upon a downstream Application and I > *want* the POST to be handled by something else. I am not sure we're talking about the exact same mechanisms here. The current proposal (which is a draft) allows the client to say: "I want the request to be handled by a script/servlet which handles my precise resource type". It does not say "I want the request to be handled by the script with name '/apps/.../foo.html'/servlet with class name 'org.acme....FooServlet'. In your case, when building a downstream application you always control the deployment and can override the servlet/script handling a certain request. Not sure if I got everything right, feel free to correct/clarify. Thanks, Robert [1]: https://issues.apache.org/jira/browse/SLING-6767
