You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by David Nuescheler <da...@day.com> on 2007/11/18 16:01:53 UTC
microsling: extension vs. mime-type script resolution
Hi guys,
I noticed that the resolution for scripts in microsling is based on
the mime-type
and not how I would have expected based on the extension.
Personally, I think that this is somewhat confusing since the rest of the
script resolution (selectors) is straight from the request url.
I think that the additional indirection to go through a mime-type table adds
complexity (since it is yet another mechanism) and is questionable to begin
with since somehow it seems to tie the response mime-type into the request
behaviour for no apparent reason. I know of a lot of cases where the
same response script offers responses in various (not limited) mime-types,
based on what the user uploaded to the repository.
Personally, I would rather just go for a straight, more direct extension-based
resolution than engaging in the whole mimetype business.
regards,
david
Re: microsling: extension vs. mime-type script resolution
Posted by David Nuescheler <da...@day.com>.
Hi Jukka,
> On Nov 20, 2007 3:26 PM, Bertrand Delacretaz <bd...@apache.org> wrote:
> > 1. The URI is split in four parts (resource path, selectors,
> > extension, suffix), where "resource path" is the longest part of the
> > request path that matches a Node in the repository
i think, that it is true that the difference between selectors and
the extension is arbitrary, and i see its value mostly for explanatory
purposes. one will end up being a filename, the other will be a
directory name.
> I would only split the URI (path) to two parts, the resource path and
> anything that comes after that. Basically, the resolver would start
> with a context node and a URI path (without any leading parts like the
> webapp or servlet path removed) and walk down the node hierarchy using
> segments of the given URI path until no matching node is found. The
> result of this resolution is a new context node and the remaining
> unresolved part of the URI path.
from an implementation standpoint i think thats a good thing to do.
from a users perspective i think there is value in guiding how to
use the flexibility with the "unresolved parts" of the url.
so one might say that this is purely a "best practices discussion",
and thats where the four parts come in handy.
> > 4. If no Servlet is found, the ScriptResolver looks for a script,
> > building its path as follows:
> > /sling/scripts/RT/ME.EXT
> I would remove this part from the resolution process within the Sling
> framework, and leave it up to a default servlet like
> SlingScriptServlet, that would construct the /RT/ME.EXT path using the
> remaining path info from step 1 above and recursively call the
> resolution process using /sling/scripts as the context to find an
> appropriate script node.
good question. I have to say that I consider leaving out the right
options, buttons and extension points the true art of building
good software. Personally, I have not run into a situation where
this way of resolving to scripts was an issue, so I see little value
in making this extensible.
> (I'd still like to use slashes
> as separators instead of dots, but that's a minor concern)
Just to make sure,
does that mean that we would have something like:
/mypage/html
/mypage/edit/html
/mypage/headimage/png
instead of
/mypage.html
/mypage.edit.html
/mypage.headimage.png
regards,
david
Re: microsling: extension vs. mime-type script resolution
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Donnerstag, den 22.11.2007, 13:41 +0200 schrieb Jukka Zitting:
> Hi,
>
> On Nov 22, 2007 11:39 AM, Felix Meschberger <fm...@gmail.com> wrote:
> > If it would just be the ScriptResolver being interested in this
> > information, then I might agree. But this is not the case. I already
> > proposed extending the ServletResolver to also take selectors, method
> > and extension into account [1]. In addition, scripts and servlets might
> > as well be interested. So I would keep this resolution at the framework
> > level and provide the data as the RequestPathInfo object.
>
> ACK, no problem. I guess a component that doesn't need the selector
> and extension parts can just use slashes as separators in which case
> the current resolution process works pretty much as envisioned.
Exactly. As far as the ResourceResolver is concerned, it treats dots and
slashes equally.
Regards
Felix
Re: microsling: extension vs. mime-type script resolution
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Nov 22, 2007 11:39 AM, Felix Meschberger <fm...@gmail.com> wrote:
> If it would just be the ScriptResolver being interested in this
> information, then I might agree. But this is not the case. I already
> proposed extending the ServletResolver to also take selectors, method
> and extension into account [1]. In addition, scripts and servlets might
> as well be interested. So I would keep this resolution at the framework
> level and provide the data as the RequestPathInfo object.
ACK, no problem. I guess a component that doesn't need the selector
and extension parts can just use slashes as separators in which case
the current resolution process works pretty much as envisioned.
BR,
Jukka Zitting
Re: microsling: extension vs. mime-type script resolution
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
-1
If it would just be the ScriptResolver being interested in this
information, then I might agree. But this is not the case. I already
proposed extending the ServletResolver to also take selectors, method
and extension into account [1]. In addition, scripts and servlets might
as well be interested. So I would keep this resolution at the framework
level and provide the data as the RequestPathInfo object.
Implementation-wise the ResourceResolver already does the proposed thing
of just cutting the request URI in two pieces. In microsling the further
split is implemented by the MicroslingRequestPathInfo class.
Regards
Felix
[1]
http://www.mail-archive.com/sling-dev@incubator.apache.org/msg00924.html
Am Donnerstag, den 22.11.2007, 10:29 +0100 schrieb Bertrand Delacretaz:
> On Nov 21, 2007 12:48 PM, Jukka Zitting <ju...@gmail.com> wrote:
>
> > ...I would only split the URI (path) to two parts, the resource path and
> > anything that comes after that. Basically, the resolver would start
> > with a context node and a URI path (without any leading parts like the
> > webapp or servlet path removed) and walk down the node hierarchy using
> > segments of the given URI path until no matching node is found. The
> > result of this resolution is a new context node and the remaining
> > unresolved part of the URI path....
>
> Ok
>
> > ...leave it up to a default servlet like
> > SlingScriptServlet, that would construct the /RT/ME.EXT path using the
> > remaining path info from step 1 above and recursively call the
> > resolution process using /sling/scripts as the context to find an
> > appropriate script node.
>
> I like the idea: split the URL in two parts only at the Sling
> framework level, and leave it up to the ScriptResolver to combine the
> resource type, method name, remaining path and extension to find a
> processing script.
>
> The change is not hard to implement, and it simplifies the Sling
> request processing, so I'm +1 on implementing it.
>
> What do others think?
>
> -Bertrand
Re: microsling: extension vs. mime-type script resolution
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Nov 21, 2007 12:48 PM, Jukka Zitting <ju...@gmail.com> wrote:
> ...I would only split the URI (path) to two parts, the resource path and
> anything that comes after that. Basically, the resolver would start
> with a context node and a URI path (without any leading parts like the
> webapp or servlet path removed) and walk down the node hierarchy using
> segments of the given URI path until no matching node is found. The
> result of this resolution is a new context node and the remaining
> unresolved part of the URI path....
Ok
> ...leave it up to a default servlet like
> SlingScriptServlet, that would construct the /RT/ME.EXT path using the
> remaining path info from step 1 above and recursively call the
> resolution process using /sling/scripts as the context to find an
> appropriate script node.
I like the idea: split the URL in two parts only at the Sling
framework level, and leave it up to the ScriptResolver to combine the
resource type, method name, remaining path and extension to find a
processing script.
The change is not hard to implement, and it simplifies the Sling
request processing, so I'm +1 on implementing it.
What do others think?
-Bertrand
Re: microsling: extension vs. mime-type script resolution
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Nov 20, 2007 3:26 PM, Bertrand Delacretaz <bd...@apache.org> wrote:
> 1. The URI is split in four parts (resource path, selectors,
> extension, suffix), where "resource path" is the longest part of the
> request path that matches a Node in the repository
I would only split the URI (path) to two parts, the resource path and
anything that comes after that. Basically, the resolver would start
with a context node and a URI path (without any leading parts like the
webapp or servlet path removed) and walk down the node hierarchy using
segments of the given URI path until no matching node is found. The
result of this resolution is a new context node and the remaining
unresolved part of the URI path.
> 2. A "resource type" is computed: if the node has a
> "slingResourceType" Property (or is that sling:resourceType, now?
> doesn't matter much for this discussion) its value is used, otherwise
> the node type is converted to a valid JCR path, and used as the
> resource type.
No changes here.
> 3. The ServletResolver looks for a Servlet that is configured to
> handle this resource type (hardcoded in microsling to serve default
> nt:file Nodes for example, OSGi-dynamic in Sling)
No changes here, except see below on how I would push functionality
from the Sling framework into the servlet level.
> 4. If no Servlet is found, the ScriptResolver looks for a script,
> building its path as follows:
>
> /sling/scripts/RT/ME.EXT
I would remove this part from the resolution process within the Sling
framework, and leave it up to a default servlet like
SlingScriptServlet, that would construct the /RT/ME.EXT path using the
remaining path info from step 1 above and recursively call the
resolution process using /sling/scripts as the context to find an
appropriate script node.
> Let's see how you'd do that, if there's a simple way that still leads
> to clear conventions I'm all ears.
My idea would actually result in little or no change to the end user
or an average Sling component developer (I'd still like to use slashes
as separators instead of dots, but that's a minor concern), but would
make the Sling internals more modular as the ScriptResolver would
essentially become just another Sling servlet component.
BR,
Jukka Zitting
Re: microsling: extension vs. mime-type script resolution
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Thanks for summarizing. There is just one minor error:
Am Dienstag, den 20.11.2007, 14:26 +0100 schrieb Bertrand Delacretaz:
> 4. If no Servlet is found, the ScriptResolver looks for a script,
> building its path as follows:
>
> /sling/scripts/RT/ME.EXT
>
> Where
>
> RT is the resource type computed in 2, filtered to make sure it is a
> valid JCR path
>
> ME is the HTTP request method name (POST, PUT) uppercased, or, for the GET
> method, the extension found in the request (html, xml, etc.), lowercase.
>
> (actually it's the content-type, not extension, but I think we just
> agreed to use
> the extension)
>
> EXT is a script extension that is acceptable for one of our script engines
> (esp, js, vlt, ...)
The path is actually /sling/scripts/RT[/SEL]/ME.EXT
where SEL is the selectors, which are inserted in the path after
converting dots to slashes; all first and then cutting off path elements
until no selector parts remain. E.g for selectors "some.print.a4", the
paths ../some/print/a4/.., ../some/print/.., ../some/.., ../.. are
tested.
Regards
Felix
Re: microsling: extension vs. mime-type script resolution
Posted by Torgeir Veimo <to...@pobox.com>.
On 20 Nov 2007, at 13:26, Bertrand Delacretaz wrote:
> I agree that this is a bit involved, but it is flexible, standardizes
> the way scripts are resolved, and the concept of a "resource type" is
> fairly unique and very useful I think .
> Let's see how you'd do that, if there's a simple way that still leads
> to clear conventions I'm all ears.
I still think that this is ok to provide as the default way to resolve
script. But in microsling it's also the only way.
--
Torgeir Veimo
torgeir@pobox.com
Re: microsling: extension vs. mime-type script resolution
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Nov 20, 2007 12:27 AM, Jukka Zitting <ju...@gmail.com> wrote:
> ...My main concern is that we are currently splitting the URIs four ways
> (resource path, selectors, extension, suffix) when I think we could do
> just as well with two parts (resource path, suffix)....
I'm not sure how you envision resolving scripts using just those two
parts, so let me describe how things work now, and you can then
suggest changes.
- o -
Currently the URI to script or servlet mapping works as follows:
1. The URI is split in four parts (resource path, selectors,
extension, suffix), where "resource path" is the longest part of the
request path that matches a Node in the repository
2. A "resource type" is computed: if the node has a
"slingResourceType" Property (or is that sling:resourceType, now?
doesn't matter much for this discussion) its value is used, otherwise
the node type is converted to a valid JCR path, and used as the
resource type.
3. The ServletResolver looks for a Servlet that is configured to
handle this resource type (hardcoded in microsling to serve default
nt:file Nodes for example, OSGi-dynamic in Sling)
4. If no Servlet is found, the ScriptResolver looks for a script,
building its path as follows:
/sling/scripts/RT/ME.EXT
Where
RT is the resource type computed in 2, filtered to make sure it is a
valid JCR path
ME is the HTTP request method name (POST, PUT) uppercased, or, for the GET
method, the extension found in the request (html, xml, etc.), lowercase.
(actually it's the content-type, not extension, but I think we just
agreed to use
the extension)
EXT is a script extension that is acceptable for one of our script engines
(esp, js, vlt, ...)
- o -
I agree that this is a bit involved, but it is flexible, standardizes
the way scripts are resolved, and the concept of a "resource type" is
fairly unique and very useful I think .
The test coverage of this parsing and mapping is also good in
microsling, so the implementation is solid.
Let's see how you'd do that, if there's a simple way that still leads
to clear conventions I'm all ears.
-Bertrand
Re: microsling: extension vs. mime-type script resolution
Posted by Shawn Anderson <sh...@gmail.com>.
I have to say that I agree with paddy on this.
/Shawn
On Nov 19, 2007 3:53 PM, Padraic I. Hannon <pi...@wasabicowboy.com> wrote:
> I guess I am a bit confused as to what is wrong with
>
> /path/to/document.pdf
> /path/to/document.html
>
> It seems to me that such a request specifies both the location of the
> content in question and provides fairly strong hints as to the template
> to run. I understand that some people may want to say that .html and
> .htm are the same file but in our experience here at edmunds it is very
> much desired not to ignore the extension. Also, someone proposed having
> scripts include other scripts when two extensions want to be act
> identically is not bad since we could address both use cases.
>
> mahalo,
> paddy
>
> Jukka Zitting wrote:
> > Hi,
> >
> > On Nov 19, 2007 11:10 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
> >
> >> On Nov 19, 2007, at 11:57 AM, Jukka Zitting wrote:
> >>
> >>> Though, on a tangent, I'm wondering if we could achieve the same use
> >>> cases with just the existing URL-to-JCR-path mapping. [...]
> >>>
> >> The disadvantage is that it makes a mess of hierarchical access control
> >> and relative links. Very bad.
> >>
> >
> > We could also do something like .../path/to/document/pdf (or even
> > ../path/to/document?format=pdf though that's a bit ugly and requires
> > special case code) to make relative links easier. Access controls
> > shouldn't be a concern as long as they're embedded within the
> > underlying repository.
> >
> > My main concern is that we are currently splitting the URIs four ways
> > (resource path, selectors, extension, suffix) when I think we could do
> > just as well with two parts (resource path, suffix). This would IMHO
> > make the URI mapping much more straightforward and flexible, at the
> > price of moving part of the mapping code from the Sling framework
> > itself to the servlet components deployed in Sling.
> >
> > BR,
> >
> > Jukka Zitting
> >
>
>
>
Re: microsling: extension vs. mime-type script resolution
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Nov 20, 2007 1:53 AM, Padraic I. Hannon <pi...@wasabicowboy.com> wrote:
> I guess I am a bit confused as to what is wrong with
>
> /path/to/document.pdf
> /path/to/document.html
I'm most concerned about two things, one minor and the other more fundamental.
The minor issue is that "." is a valid JCR name character, so using it
as a separator is IMHO a bit counterintuitive. Though I must admit
that Sling handles this pretty well and the resulting URIs often look
quite natural (like something served from a filesystem).
The more fundamental issue is that IMHO Sling hardcodes way too much
of the URI mapping process. The whole process is quite complicated and
filled with string parsing and constructing, repository traversal,
etc. I'm left wondering if we really do need all this. I believe we
could achieve all the same functionality and a lot more flexibility
with a cleaner URI mapping approach.
BR,
Jukka Zitting
Re: microsling: extension vs. mime-type script resolution
Posted by "Padraic I. Hannon" <pi...@wasabicowboy.com>.
I guess I am a bit confused as to what is wrong with
/path/to/document.pdf
/path/to/document.html
It seems to me that such a request specifies both the location of the
content in question and provides fairly strong hints as to the template
to run. I understand that some people may want to say that .html and
.htm are the same file but in our experience here at edmunds it is very
much desired not to ignore the extension. Also, someone proposed having
scripts include other scripts when two extensions want to be act
identically is not bad since we could address both use cases.
mahalo,
paddy
Jukka Zitting wrote:
> Hi,
>
> On Nov 19, 2007 11:10 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
>
>> On Nov 19, 2007, at 11:57 AM, Jukka Zitting wrote:
>>
>>> Though, on a tangent, I'm wondering if we could achieve the same use
>>> cases with just the existing URL-to-JCR-path mapping. [...]
>>>
>> The disadvantage is that it makes a mess of hierarchical access control
>> and relative links. Very bad.
>>
>
> We could also do something like .../path/to/document/pdf (or even
> ../path/to/document?format=pdf though that's a bit ugly and requires
> special case code) to make relative links easier. Access controls
> shouldn't be a concern as long as they're embedded within the
> underlying repository.
>
> My main concern is that we are currently splitting the URIs four ways
> (resource path, selectors, extension, suffix) when I think we could do
> just as well with two parts (resource path, suffix). This would IMHO
> make the URI mapping much more straightforward and flexible, at the
> price of moving part of the mapping code from the Sling framework
> itself to the servlet components deployed in Sling.
>
> BR,
>
> Jukka Zitting
>
Re: microsling: extension vs. mime-type script resolution
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Nov 19, 2007 11:10 PM, Roy T. Fielding <fi...@gbiv.com> wrote:
> On Nov 19, 2007, at 11:57 AM, Jukka Zitting wrote:
> > Though, on a tangent, I'm wondering if we could achieve the same use
> > cases with just the existing URL-to-JCR-path mapping. [...]
>
> The disadvantage is that it makes a mess of hierarchical access control
> and relative links. Very bad.
We could also do something like .../path/to/document/pdf (or even
../path/to/document?format=pdf though that's a bit ugly and requires
special case code) to make relative links easier. Access controls
shouldn't be a concern as long as they're embedded within the
underlying repository.
My main concern is that we are currently splitting the URIs four ways
(resource path, selectors, extension, suffix) when I think we could do
just as well with two parts (resource path, suffix). This would IMHO
make the URI mapping much more straightforward and flexible, at the
price of moving part of the mapping code from the Sling framework
itself to the servlet components deployed in Sling.
BR,
Jukka Zitting
Re: microsling: extension vs. mime-type script resolution
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Nov 19, 2007, at 11:57 AM, Jukka Zitting wrote:
> On Nov 18, 2007 5:01 PM, David Nuescheler <da...@day.com> wrote:
>> Personally, I would rather just go for a straight, more direct
>> extension-based
>> resolution than engaging in the whole mimetype business.
>
> +1
>
> Though, on a tangent, I'm wondering if we could achieve the same use
> cases with just the existing URL-to-JCR-path mapping. For example,
> instead of:
>
> .../path/to/document.html
> .../path/to/document.pdf
> .../path/to/document.json
> .../path/to/document.atom
>
> We could do something like this:
>
> .../path/to/document
> .../pdf/path/to/document
> .../json/path/to/document
> .../atom/path/to/document
>
> With actual /pdf, /json, and /atom nodes within the repository to
> dispatch the desired processing or rendering functionality. The nice
> thing about this approach is that we could more easily have customized
> behaviour per subtree:
>
> .../path/pdf/to/document
>
> In fact I'd even consider doing the same for selectors to simplify the
> URL mapping process to a direct path walk.
The disadvantage is that it makes a mess of hierarchical access control
and relative links. Very bad. The only time I use that approach is for
language selection, which tends to create its own "locality of
reference"
that is better organized as separate sites/trees of content.
For various reasons (mostly to do with cool URIs being decoupled from
the implementation), it is better to have one exposed URI path like
../path/to/document
with a virtual node that means "indirect to default selectors" or
"indirect to selectors based on content negotiation." Then, a set of
more-specific URIs w/selectors for each variant can be used as the
target of the URI indirection, and also for direct links
to non-negotiated resources.
The only real advantage of mime-type based script resolution is that
it gives more flexibility for old URIs to be creatively redirected
to newer implementations. A better solution is to simply build-in
a URI indirection mechanism that can set on a per-URI basis.
....Roy
Re: microsling: extension vs. mime-type script resolution
Posted by pi...@wasabicowboy.com.
+1 for extension based
Aloha
Paddy
Sent via BlackBerry from T-Mobile
-----Original Message-----
From: "Bertrand Delacretaz" <bd...@apache.org>
Date: Tue, 20 Nov 2007 14:06:56
To:sling-dev@incubator.apache.org
Subject: Re: microsling: extension vs. mime-type script resolution
On Nov 19, 2007 8:57 PM, Jukka Zitting <ju...@gmail.com> wrote:
> On Nov 18, 2007 5:01 PM, David Nuescheler <da...@day.com> wrote:
> > ...Personally, I would rather just go for a straight, more direct extension-based
> > resolution than engaging in the whole mimetype business....
>
> +1
Agreed, IIRC it was me who introduced the mime-type based thing, in my
quest to expose REST ideas.
But after reading the debate, and especially Marcel's excellent
vnd.ms-excel.esp vs. xsl.esp example, I agree that looking up the
script based on the request's extension (or using GET as the script
name if no extension) is easier to understand, and less risky.
And if the Accept header is used (which IMHO is sometimes a good idea
when the client is a machine, not a browser), the script can access it
as needed.
I'll create a JIRA issue for this change to extension-based script
resolution (unless the tangent taken by Jukka brings other ideas, I
haven't fully read that part of the thread yet ;-)
-Bertrand
Re: microsling: extension vs. mime-type script resolution
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Nov 19, 2007 8:57 PM, Jukka Zitting <ju...@gmail.com> wrote:
> On Nov 18, 2007 5:01 PM, David Nuescheler <da...@day.com> wrote:
> > ...Personally, I would rather just go for a straight, more direct extension-based
> > resolution than engaging in the whole mimetype business....
>
> +1
Agreed, IIRC it was me who introduced the mime-type based thing, in my
quest to expose REST ideas.
But after reading the debate, and especially Marcel's excellent
vnd.ms-excel.esp vs. xsl.esp example, I agree that looking up the
script based on the request's extension (or using GET as the script
name if no extension) is easier to understand, and less risky.
And if the Accept header is used (which IMHO is sometimes a good idea
when the client is a machine, not a browser), the script can access it
as needed.
I'll create a JIRA issue for this change to extension-based script
resolution (unless the tangent taken by Jukka brings other ideas, I
haven't fully read that part of the thread yet ;-)
-Bertrand
Re: microsling: extension vs. mime-type script resolution
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Nov 18, 2007 5:01 PM, David Nuescheler <da...@day.com> wrote:
> Personally, I would rather just go for a straight, more direct extension-based
> resolution than engaging in the whole mimetype business.
+1
Though, on a tangent, I'm wondering if we could achieve the same use
cases with just the existing URL-to-JCR-path mapping. For example,
instead of:
.../path/to/document.html
.../path/to/document.pdf
.../path/to/document.json
.../path/to/document.atom
We could do something like this:
.../path/to/document
.../pdf/path/to/document
.../json/path/to/document
.../atom/path/to/document
With actual /pdf, /json, and /atom nodes within the repository to
dispatch the desired processing or rendering functionality. The nice
thing about this approach is that we could more easily have customized
behaviour per subtree:
.../path/pdf/to/document
In fact I'd even consider doing the same for selectors to simplify the
URL mapping process to a direct path walk.
BR,
Jukka Zitting
Re: microsling: extension vs. mime-type script resolution
Posted by Marcel Reutegger <ma...@day.com>.
Felix Meschberger wrote:
> Am Sonntag, den 18.11.2007, 16:01 +0100 schrieb David Nuescheler:
>> I noticed that the resolution for scripts in microsling is based on
>> the mime-type
>> and not how I would have expected based on the extension.
>
> Actually, the resolution is based on the request url extension, only
> that there is some kind of an indirection, others call this
> abstraction :-)
abstraction is certainly useful in general, but we should make sure it doesn't
make microsling more complicated to use and understand. I must admit I'd rather
call this an indirection than an abstraction, because I have know what the
mime-type for a certain resource is. Moreover I also have to make sure the
mapping from extension to mime-type is available somewhere. This adds additional
complexity to development and deployment.
> The problem is, that the extension is not all the times
> unique. For example, there are people using .htm and others that are
> using .html but all of them mean text/html. So instead of requiring two
> scripts for .htm and .html, we just require html (for text/html).
I think this can be solved quite easily by including an existing script. e.g. if
you already have a html.esp and now want to support the .htm extension, simply
create a htm.esp and include html.esp.
there's also the other side of the story. for a mime-type there may exist
multiple extension that refer to it. e.g. excel files. both xls and xlt (the
template) have the same mime type: application/vnd.ms-excel
This may be quite unfortunate if you want to treat the template differently.
Besides, do I really have to name the script vnd.ms-excel.esp? xsl.esp seems so
much more intuitive.
regards
marcel
Re: microsling: extension vs. mime-type script resolution
Posted by pi...@wasabicowboy.com.
One thing to point out as well is that by using mime type and supporting both htm and html extensions can have serious impacts, according to our seo team, on search engine rankings as engines may treat such pages as different thus causing duplicate content penalties.
Paddy
Sent via BlackBerry from T-Mobile
-----Original Message-----
From: "David Nuescheler" <da...@day.com>
Date: Sun, 18 Nov 2007 18:40:05
To:sling-dev@incubator.apache.org
Subject: Re: microsling: extension vs. mime-type script resolution
Hi Felix,
thanks for shedding some more light on the rationale.
> Actually, the resolution is based on the request url extension, only
> that there is some kind of an indirection, others call this
> abstraction :-) The problem is, that the extension is not all the times
> unique. For example, there are people using .htm and others that are
> using .html but all of them mean text/html. So instead of requiring two
> scripts for .htm and .html, we just require html (for text/html).
I still don't understand why anyone would require two scripts.
In the end it is not up to the surfer to just decide to choose their
extension. Much like in the static webserver case where the webmaster
decides which extension to use either .html or .htm for his static
files the person that builds microsling website would decide how
their extensions are mapped.
I can't even come up with a usecase where a "magic" .html and .htm
extension equivalence would add value.
Actually in our current version of our WCMS we also offer flexibility
on the extension (interestingly enough back then with the exact
same .html & .htm issue in mind) but after ~10 years of using it, I have
to say, there really is absolutely no need for it, and I would never
be in favour of something like that.
> It gets of course more interesting in the case where there is no request
> extension: What script should we select ? Currently, we default to
> text/plain, which is probably not the correct solution.
I think that just illustrates the issue at hand in a very clear way.
My expectation was that if I have no extension, I would map no script at all.
(well, to the GET.esp script, if I really needed to,
which in most cases should stay untouched and I would really encourage
to have the standard WebDAV GET to be executed, which in my mind is
perfect in most cases)
> > I think that the additional indirection to go through a mime-type table adds
> > complexity (since it is yet another mechanism) and is questionable to begin
> > with since somehow it seems to tie the response mime-type into the request
> > behaviour for no apparent reason.
> In fact there is one reason, and I think this reason validates it all:
> The client tells by means of the request, what he or she expects. So in
> the same way as the request URL indicates the desired content to be
> delivered, the response mime-type is derived from (a) the client request
> URL and (b) to the HTTP Accept header (not implemented in microsling,
> yet to be done in Sling) to indicate the expected response content type.
> This is no tie-in, just trying to meet up with the client's expectation.
Personally I am afraid to have accept-header influence the response
mime-type.
Frankly, in real live I have never seen something like that implemented
and I would be scared to only anticipate the effects on proxies and
reverse proxies. Also I think that clients are not very specific about that.
I really would recommend to serve up resources that differ in mimetype
with different URLs.
Personally, I would probably stay away from building any behaviors
on accept headers.
> > I know of a lot of cases where the
> > same response script offers responses in various (not limited) mime-types,
> > based on what the user uploaded to the repository.
> Well, this is a delicate issue: If as a client I request something with
> extension .txt I do expect a plain text response and not a GIF and I do
> absolutely not care what some other guy might have stored in the
> repository. If of course there is not plain text representation of the
> addressed content, I would expect an appropriate HTTP status code.
Some clients (Firefox) base their mime-type handling strictly on the response
content-type header, others use a mix of extension, actual content and headers
(IE). So I agree that it is very good practice if the content-type header,
the extension and actual content match up. No doubt.
I am not talking about extension to mime-type mappings like txt or html.
Very frequently extensions like: .do, .jsp, .asp map to all sorts of mimetypes
so the real-life web infrastructure is certainly capable of dealing with
a 1-to-many relationship between extensions and mime-types.
Well, let's look at the following examples:
Assume that /myuploads is a node that is used to spool uploaded
nt:resource nodes for one reason or another.
Let's say I have jpg called my.jpg (which could also be a my.pdf ;)
Now for the script resolution I would like to map .spool to my spool.esp
rather than anything even vaguely related to a mime-type.
/myuploads.spool/my.jpg
or
/myuploads.spool/my.jpg?get=1234-123423-34234-23455
> Hope, this makes my case clear for using the response content type for
> the script resolution,
I may not see it. To me this is just a dangerous and problematic indirection
with a lot of potential for errors. Let's say my extensions-mimetype table
is different from an other microsling install that I copy my scripts from then
things don't work out as expected. Syncing up peoples mime-type tables
does definitely not sound like a good plan to me.
> whereas the response content type is derived from
> the request extension (and in Sling in the future probably also from the
> Accept HTTP header).
In my mind this would be a very good default, but I would really leave this
up to the script developer to override. Just like everybody else ;)
regards,
david
Re: microsling: extension vs. mime-type script resolution
Posted by David Nuescheler <da...@day.com>.
Hi Felix,
thanks for shedding some more light on the rationale.
> Actually, the resolution is based on the request url extension, only
> that there is some kind of an indirection, others call this
> abstraction :-) The problem is, that the extension is not all the times
> unique. For example, there are people using .htm and others that are
> using .html but all of them mean text/html. So instead of requiring two
> scripts for .htm and .html, we just require html (for text/html).
I still don't understand why anyone would require two scripts.
In the end it is not up to the surfer to just decide to choose their
extension. Much like in the static webserver case where the webmaster
decides which extension to use either .html or .htm for his static
files the person that builds microsling website would decide how
their extensions are mapped.
I can't even come up with a usecase where a "magic" .html and .htm
extension equivalence would add value.
Actually in our current version of our WCMS we also offer flexibility
on the extension (interestingly enough back then with the exact
same .html & .htm issue in mind) but after ~10 years of using it, I have
to say, there really is absolutely no need for it, and I would never
be in favour of something like that.
> It gets of course more interesting in the case where there is no request
> extension: What script should we select ? Currently, we default to
> text/plain, which is probably not the correct solution.
I think that just illustrates the issue at hand in a very clear way.
My expectation was that if I have no extension, I would map no script at all.
(well, to the GET.esp script, if I really needed to,
which in most cases should stay untouched and I would really encourage
to have the standard WebDAV GET to be executed, which in my mind is
perfect in most cases)
> > I think that the additional indirection to go through a mime-type table adds
> > complexity (since it is yet another mechanism) and is questionable to begin
> > with since somehow it seems to tie the response mime-type into the request
> > behaviour for no apparent reason.
> In fact there is one reason, and I think this reason validates it all:
> The client tells by means of the request, what he or she expects. So in
> the same way as the request URL indicates the desired content to be
> delivered, the response mime-type is derived from (a) the client request
> URL and (b) to the HTTP Accept header (not implemented in microsling,
> yet to be done in Sling) to indicate the expected response content type.
> This is no tie-in, just trying to meet up with the client's expectation.
Personally I am afraid to have accept-header influence the response
mime-type.
Frankly, in real live I have never seen something like that implemented
and I would be scared to only anticipate the effects on proxies and
reverse proxies. Also I think that clients are not very specific about that.
I really would recommend to serve up resources that differ in mimetype
with different URLs.
Personally, I would probably stay away from building any behaviors
on accept headers.
> > I know of a lot of cases where the
> > same response script offers responses in various (not limited) mime-types,
> > based on what the user uploaded to the repository.
> Well, this is a delicate issue: If as a client I request something with
> extension .txt I do expect a plain text response and not a GIF and I do
> absolutely not care what some other guy might have stored in the
> repository. If of course there is not plain text representation of the
> addressed content, I would expect an appropriate HTTP status code.
Some clients (Firefox) base their mime-type handling strictly on the response
content-type header, others use a mix of extension, actual content and headers
(IE). So I agree that it is very good practice if the content-type header,
the extension and actual content match up. No doubt.
I am not talking about extension to mime-type mappings like txt or html.
Very frequently extensions like: .do, .jsp, .asp map to all sorts of mimetypes
so the real-life web infrastructure is certainly capable of dealing with
a 1-to-many relationship between extensions and mime-types.
Well, let's look at the following examples:
Assume that /myuploads is a node that is used to spool uploaded
nt:resource nodes for one reason or another.
Let's say I have jpg called my.jpg (which could also be a my.pdf ;)
Now for the script resolution I would like to map .spool to my spool.esp
rather than anything even vaguely related to a mime-type.
/myuploads.spool/my.jpg
or
/myuploads.spool/my.jpg?get=1234-123423-34234-23455
> Hope, this makes my case clear for using the response content type for
> the script resolution,
I may not see it. To me this is just a dangerous and problematic indirection
with a lot of potential for errors. Let's say my extensions-mimetype table
is different from an other microsling install that I copy my scripts from then
things don't work out as expected. Syncing up peoples mime-type tables
does definitely not sound like a good plan to me.
> whereas the response content type is derived from
> the request extension (and in Sling in the future probably also from the
> Accept HTTP header).
In my mind this would be a very good default, but I would really leave this
up to the script developer to override. Just like everybody else ;)
regards,
david
Re: microsling: extension vs. mime-type script resolution
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Sonntag, den 18.11.2007, 16:01 +0100 schrieb David Nuescheler:
> I noticed that the resolution for scripts in microsling is based on
> the mime-type
> and not how I would have expected based on the extension.
Actually, the resolution is based on the request url extension, only
that there is some kind of an indirection, others call this
abstraction :-) The problem is, that the extension is not all the times
unique. For example, there are people using .htm and others that are
using .html but all of them mean text/html. So instead of requiring two
scripts for .htm and .html, we just require html (for text/html).
It gets of course more interesting in the case where there is no request
extension: What script should we select ? Currently, we default to
text/plain, which is probably not the correct solution.
> I think that the additional indirection to go through a mime-type table adds
> complexity (since it is yet another mechanism) and is questionable to begin
> with since somehow it seems to tie the response mime-type into the request
> behaviour for no apparent reason.
In fact there is one reason, and I think this reason validates it all:
The client tells by means of the request, what he or she expects. So in
the same way as the request URL indicates the desired content to be
delivered, the response mime-type is derived from (a) the client request
URL and (b) to the HTTP Accept header (not implemented in microsling,
yet to be done in Sling) to indicate the expected response content type.
This is no tie-in, just trying to meet up with the client's expectation.
> I know of a lot of cases where the
> same response script offers responses in various (not limited) mime-types,
> based on what the user uploaded to the repository.
Well, this is a delicate issue: If as a client I request something with
extension .txt I do expect a plain text response and not a GIF and I do
absolutely not care what some other guy might have stored in the
repository. If of course there is not plain text representation of the
addressed content, I would expect an appropriate HTTP status code.
Hope, this makes my case clear for using the response content type for
the script resolution, whereas the response content type is derived from
the request extension (and in Sling in the future probably also from the
Accept HTTP header).
Regards
Felix