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.
James
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]
