Hi,

Looking back in history, we once discussed this and decided to only
support selectors and extensions for GET requests. The reason for this
IIRC was that we thought non-GET requests would generally be uniformely
handled and extensions and selectors have nothing to do with non-GET
requests.

In the meantime, we loosened this and decided to consider selectors for
selecting scripts for non-GET requests. Considering this I am very much
in favor of supporting extensions for non-GET requests in general.

So I would even go a step further define the name of scripts considered
for request processing as follows:

     [ (parent | selector) ] [ "." extension ] [ "." method ]
               "." scriptExtension

where
  parent     - the name of the parent resource
  selector   - a request selector
  extension  - the request extension
               may be omitted if "html"
  method     - the request method
               may be omitted if "GET" or "HEAD"


For example, a JSP script to handle a request POST /content/a.sel.html
may be named as follows (assuming /content/a is nt:file) :


       .../file/file.POST.jsp         ( parent method .jsp )
       .../file/sel.POST.jsp          ( selector method .jsp )
       ----------------------------------------------------------------
       .../file/file.html.POST.jsp    ( parent extension method .jsp )
       .../file/sel.html.POST.jsp     ( selector extension method .jsp )
       .../file/html.POST.jsp         ( extension method .jsp )
       ----------------------------------------------------------------
       .../file/POST.jsp              ( method .jsp )


Likewise a JSP script to handle a request GET /content/a.sel.html may be
named as follows (again assuming /content/a is nt:file) :


       .../file/file.jsp             ( parent .jsp )
       .../file/sel.jsp              ( selector .jsp )
       ----------------------------------------------------------------
       .../file/file.html.jsp        ( parent extension .jsp )
       .../file/sel.html.jsp         ( selector extension .jsp )
       .../file/html.jsp             ( extension .jsp )
       ----------------------------------------------------------------
       .../file/file.html.GET.jsp    ( parent extension method .jsp )
       .../file/sel.html.GET.jsp     ( selector extension method .jsp )
       .../file/html.GET.jsp         ( extension method .jsp )
       ----------------------------------------------------------------
       .../file/file.GET.jsp         ( parent method .jsp )
       .../file/sel.GET.jsp          ( selector method .jsp )
       ----------------------------------------------------------------
       .../file/GET.jsp              ( method .jsp )


I think, this basically treats all methods and extensions equal in the
basic support of script names. It treats the .html request extension
more equal in that it needs not be contained in the script name for a
script to handle the request. It also treats the GET and HEAD request
methods more equal in that they need not be contained in the script name
for a script to handle the request.

WDYT ?

Regards
Felix


Alexander Klimetschek schrieb:
> Hi all,
> 
> with SLING-748 [1] the script resolution process was extended to
> include selectors for non-GET/HEAD request, eg. POST. I now want to
> ask to also include the request extension in the script resolution
> process for all HTTP methods. Thus you could register those scripts:
> 
> /apps/sling/servlet/default/ext.POST.servlet   => handles POST to
> ...../something.ext
> /apps/sling/servlet/default/selector/ext.POST.servlet   => handles
> POST to ...../something.selector.ext
> 
> This is mostly useful when you are registering a script or servlet for
> the default resource type and want to separate them via selectors
> and/or extensions, in order to *not* overwrite Sling's default POST
> servlet. The use case is somewhat similar to my proposal in SLING-864
> [2] - it's about importing files at arbitrary locations in the
> repository, ie. when you don't have a specific resource type set on
> the path you import into. (In SLING-864 it was even about non-existing
> paths).
> 
> IMHO it is only consistent to allow round-tripping on the same
> resource URL, whereas in both cases a custom servlet is handling the
> requests:
> 
> POST /some/path.ext   => handled by custom IMmporter servlet at
> /apps/sling/servlet/default/ext.POST.servlet
> GET /some/path.ext   => handled by custom EXporter servlet at
> /apps/sling/servlet/default/ext.servlet
> 
> WDYT?
> 
> [1] https://issues.apache.org/jira/browse/SLING-748
> [2] https://issues.apache.org/jira/browse/SLING-864
> 
> Regards,
> Alex
> 

Reply via email to