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?
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]
