Hi Bill,
On Aug 23, 2006, at 3:35 PM, William A. Rowe, Jr. wrote:
James Berry wrote:
What I'm saying is that they should not be treated independently or
differently. They should be treated not as metadata, but as part
of the
segment.
To be 100% clear; this is what Apache httpd does today. If you ask
for
foo.html;v=1 it will open the -file- foo.html;v=1 or fail. What jk or
tomcat does with the same is up to those components, but httpd has no
magic whatsoever which is what you want. You would like the same of
Tomcat. But...
...this would be valid if /servlet/MyApplication;v=1 invokes the class
MyApplication;v=1
Yes, I would expect it to invoke the class "MyApplication;v=1". I
hadn't considered the other behavior.
and not MyApplication with a parameter of v=1.
If it invokes the class MyApplication then we can't follow your
philosophy
since the permissions were likely to apply to the servlet class and
not
to the precise syntax the user called MyApplication with.
That's not what I'm asking for. It's an interesting idea, but as
you've pointed out, might require significantly more work and thought
to get right.
I'm simply asking that Tomcat not mangle urls that contain
parameters. The cases in which I'd be interested in using parameters
are below the servlet level (in pathinfo), so invoking servlets with
such parameters, while conceivably interesting, is by no means
necessary.
I'd ask that, for now, special case handling of parameters be
removed. If at some point in the future support was added to
specially parse parameters and pass them into servlets, then I'd
assume there would have to be special configuration to enable such
behavior. So allowing the more wide open general case behavior that
I'm asking for now wouldn't prevent such support in the future, as
parameters to servlets would presumably only be parsed if such
behavior was enabled.
Given the present behavior, however, any use of parameters is
disallowed, which seems overly restrictive, and certainly prevents a
broad range of interesting application for segment parameters.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
