Thanks so much for that snippet; I notice in there no mention of filename extensions but instead they talk of parsing the string form and give no special meaning to the dot.
It is a difficult question hard to answer in an email without a great deal of study, but to be naive and bold about it, what I believe what I am seeing are the opposite, I am seeing Hierarchical URI which are Relative URI but are not acceptable to the TC implementation. I found just now they are not acceptable to winstone either. Here is an example: http://host:8080/clock/thetimeisnow/utc is perfectly valid and semantic in the sense that in the collection of clock resources there exists "thetimeisnow" resource wherein we can request the time now in UTC. That seems natural and reasonable. Where it gets fuzzy given the current implementation is if I introduce a dot character, which in the article you quote is nowhere said to be anything more than just another char http://host:8080/clock/thetimeis.now/utc the semantic meaning of my dot is maybe dubious ;) but nonetheless, what I am hearing in the thread here is that I have introduced a CPM/MSDOS convention from the middle 70's that now changes the URI from a valid expression into an invalid one. From a strictly information-retrieval point of view this makes little sense. But it still may have a valid generic pattern-recognition rule that would let the server-side realize that we are calling the servlet generated from thetimeis.now.java, which I am nearly certain would pass the javac and would load and obtain PathInfo as expected. So now ... http://host:8080/clock/thetimeis.jsp/utc becomes 404 not found; it is still a string, still semantically partitioning the namespace of the clock tools, only, for the server-side techno-convenience, I wish to employ a pattern recognition of the (.*\.jsp)(.*) to return the script name in $1 and the PathInfo in $2; to the Java code within the main body of the JSP, the use of getPathInfo() does as expected, to the servlet container the pattern extracts the script for Jasper processing, adding the remaining path as the PathInfo. but this is considered invalid and undesirable behaviour. That is the issue I struggle to understand and I will re-read that spec a few times, but on the first two readings I do not find any rule that demands that the active server trigger term of the URI must needs be the terminal token *iff* that token contains a servlet-mapped CPM/MSDOS extension suffix routing to a script interpreter. I mean, clearly I'm wrong, I'm just trying to see *why* I am wrong. To my mind, a URI should be completely implementation independent and all valid URI token characters should be valid regardless of the underlying technology. On Wed, Dec 15, 2010 at 10:23 AM, Martin Gainty <mgai...@hotmail.com> wrote: > > > my question is: > are you seeing implementations (in TC) of a Hierarchical URI which is NOT > Absolute URI > or Relative URI > > > -- *Have Blog, Will Travel: blog.teledyn.com* *A Serviceable Substitute: post.teledyn.com*
