Hi,

I'm not seeing how SLING-2670 changes the picture, it just makes
accessing the suffix easier, but still the extension is appended to
the existing resource, so it's still:
http://host/bin/sample.ext/some/more/info
and not http://host/bin/sample/some/more/info.ext

As this already works with servlets, I don't feel we should change this.

The use case in SLING-2726 can easily be implemented with a very
simple resource provider, the use case of SLING-2670 works with
servlets. So unless we have a different use case, I think we should
leave it as is.

Regards
Carsten

2013/2/19 Felix Meschberger <fmesc...@adobe.com>:
> Hi
>
> In SLING-2726 [1] it is requested that registered servlets are made 
> accessible as if they would have been registered with a prefix instead of an 
> fixed path.
>
> The reasoning for declining the request is that Sling addresses resources, 
> that servlets are not to be considered resources, that servlets are 
> rendering, and that everything not going through the repository does not 
> benefit from automatic access control.
>
> Looking at what we have: A servlet is addressable by its exact path or if the 
> servlet path is the prefix to the URL and that prefix path has an extension. 
> For example a Servlet registered at /bin/sample is accessible with both of 
> the following URLs:
>
>   * http://host/bin/sample
>   * http://host/bin/sample.ext/some/more/info
>
> As part of another request (SLING-2670 [2]) we will be adding support to 
> access the request suffix as if it would address another resource to allow 
> for admin requests to servlets which handle secondary resources.
>
> In this context, allowing for servlet registrations to be prefixes instead of 
> fixed paths is nothing new. The only change is that the mandatory extension, 
> which makes the URL ugly (see second example above), is not required any 
> longer.
>
> Regards
> Felix
>
>
> [1] https://issues.apache.org/jira/browse/SLING-2726
> [2] https://issues.apache.org/jira/browse/SLING-2670



-- 
Carsten Ziegeler
cziege...@apache.org

Reply via email to