tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Lawrence Murphy <ga...@teledyn.com>
Subject Re: troubleshooting getPathInfo in jsp files
Date Wed, 15 Dec 2010 16:24:58 GMT
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 <mgainty@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*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message