Hi Jean-Frederic,
On Aug 23, 2006, at 1:24 PM, Jean-frederic Clere wrote:
James Berry wrote:
Jean-Frederic, Bill, Remy,
I didn't get any response to this, but would really like to hear
your thoughts on this issue of parameters within URL path
segments, which tomcat current does not allow. Can you give me
any feedback?
http://example.com/this;biz=bar;foo/that;v=1.1/whatever
The question is to which "context" such a request has to be mapped?
http://example.com/this/that and servlet whatever?
My response is that the tomcat should be completely blind to
"parameters". Basically, to Tomcat's perspective, they don't exist.
There is nothing any more special about "this;biz=bar" than
"this,biz=bar" or "this-biz-bar".
So if there is no context with the name "this;biz=bar" then tomcat
should do whatever it does when there is no context
"undefinedcontext". Same with servlet mapping.
Tomcat should be blind to the very existence of parameters because it
doesn't place any meaning on them. And frankly, since it doesn't, I'm
probably not very likely to try to give you a url such as that one,
because there's no reason to make such an ugly url, but I guess it
makes a good argument, and perhaps a good example.
A more realistic url I might use is:
http://example.com/context/servlet/sega;with=parameters/
segb;v=1.0;b;c/segc
In such a case, my servlet would would parse the pathinfo and do
something meaningful with the parameters.
My point, however, is that currently I cannot do the later, because
tomcat is trying to be too smart. It doesn't support any meaning for
the parameter syntax, and so, rather than tossing any path that
contains parameters, it should just be blind to the fact that they
are there. If somebody creates a url scheme that uses them, Tomcat
shouldn't stand in their way.
James
What do you want to do will biz=bar and foo?
v=1.1... means that you want version 1.1 of that, no?
Cheers
Jean-Frederic
Thanks!
James
On Aug 21, 2006, at 8:42 PM, James Berry wrote:
On Aug 21, 2006, at 6:26 PM, James Berry wrote:
Guys,
Sorry to open up this subject again. I've just read the mails
in this thread:
http://marc.theaimsgroup.com/?l=tomcat-
dev&m=115344110306194&w=2
http://marc.theaimsgroup.com/?l=tomcat-
dev&m=115346837428224&w=2
Though I can't say I paid particular attention to the jkmount
situation (and so I can't testify as to how treatment of such
parameters might affect that), I can say that I'd like to be
able to use ;parameter=value in my path segments in a tomcat
environment:
http://example.com/this;biz=bar;foo/that;v=1.1/whatever
To me, this looks completely valid per rfc 2396, 2616, and
3986, and it's a surprise to me that tomcat strips any path
following the first such parameter.
I would like to see tomcat essentially ignore the fact that ';'
exists in a path segment, and pass it on into the servlet
unmodified to do with as it pleases.
In fact, I don't see any motivation for any special handling of
semicolon vs any other of the other sub-delims characters, none
of which tomcat does anything special with. Comma and Plus are
allowed in path segments, for instance; why is semicolon
treated differently? The more recent RFCs say that there is
nothing special that the server/container should do with such a
character when it appears in a path segment.
Obviously, of course, there would be places where it would be
plain wrong to place such a parameter/character (if it didn't
map to a servlet, or to a file, or...) but there are other
places (in extra path segments in pathInfo, for instance) where
the interpretation of such characters should NOT BE made by the
server, but by the ultimate consumer of those bits. Therefore,
the server should simply not place any special meaning on such
characters in any path segment.
I'm inspired by the following paragraph in G.4 of rfc 2396:
Extensive testing of current client applications
demonstrated that
the majority of deployed systems do not use the ";" character to
indicate trailing parameter information, and that the
presence of a
semicolon in a path segment does not affect the relative
parsing of
that segment. Therefore, parameters have been removed as a
separate
component and may now appear in any path segment. Their
influence
has been removed from the algorithm for resolving a relative URI
reference. The resolution examples in Appendix C have been
modified
to reflect this change.
And also by the following from rfc 3986:
Aside from dot-segments in hierarchical paths, a path segment is
considered opaque by the generic syntax. URI producing
applications
often use the reserved characters allowed in a segment to
delimit
scheme-specific or dereference-handler-specific
subcomponents. For
example, the semicolon (";") and equals ("=") reserved
characters are
often used to delimit parameters and parameter values
applicable to
that segment. The comma (",") reserved character is often
used for
similar purposes. For example, one URI producer might use a
segment
such as "name;v=1.1" to indicate a reference to version 1.1 of
"name", whereas another might use a segment such as "name,
1.1" to
indicate the same. Parameter types may be defined by scheme-
specific
semantics, but in most cases the syntax of a parameter is
specific to
the implementation of the URI's dereferencing algorithm.
Note that the segment syntax in rfc 3986 explicitly allows sub-
delims (through pchar), of which ';' is but one.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
