Hi,
I have been talking with Carsten and Robert offline about a better solution
to replace the URIProvider which to be frank, isn't really working for us.
For those that don't know, its used inside the Slng Default Get servlet to
allow that servlet to return a redirect instead of sending a stream of
bytes. Typically the redirect would be a to a service better suited to
streaming the bytes of a binary.
The problem with the URIProvider is the API only sees a Resource so can
determine the context of the request, the FQDN or any other information
about the request.
Initially I suggested adding a method to the URIProvider, but Carsten said
that would break implementations.
We discussed deprecating URIProvider so that anyone using it can still use
it, but adding a new provider (ie new interface) that can given a request
from which a provider implementation would return a status code, and
headers. If the status code is not -1 then the headers would added to the
response and the response returned.
Initially I suggested both request and response objects were give to the
provider. Carsten preferred not to give the response object as this could
allow he provider implementation to do too much.
ie
interface RedirectProvider {
/**
* @param request The request
* @param responseHeaders a list of headers to be filled by the provider
* and added to the response if the return is a http status
code.
* @returns -1 if no action to be taken, or a http status code if a
response is to
* created with that status code.
*/
int getRedirect(HttpServletRequest request, List<String[]> responseHeaders);
}
wdyt? Is this something Sling can consider. If so I would volunteer to do a
PR, but I would not want to invest the effort if there is no appetite.
Best Regards
Ian
