DO NOT REPLY [Bug 3727] - Switched included request parameters

2001-09-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727

Switched included request parameters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2001-09-26 17:28 ---
My tests confirm what Bill Barker has said. If you have a mapping for /*,
requests that don't otherwise match some other mapping will have the
servlet_path empty and path_info non-empty.  See section 4.4 in the Servlet 2.3
spec (this behavior didn't change from 2.2 and the Servlet 2.3 spec has some
typo's fixed that are present in the Servlet 2.2 spec). If you take either
the /lawn/* or /garden/* examples and replace the /lawn or /garden
with , you will see that the servlet_path becomes blank.  Thus your statement
in the last reopen is incorrect.  The servlet_path and path_info are not 
switched.

More to come...



DO NOT REPLY [Bug 3727] - Switched included request parameters

2001-09-26 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727

Switched included request parameters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|tomcat- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |
 Status|ASSIGNED|NEW



--- Additional Comments From [EMAIL PROTECTED]  2001-09-26 17:29 ---
I tried adding the /foobar/* dummy mapping and behavior did not change as it
shouldn't.  If you are still able to get altered behavior when adding a dummy
mapping, please specify the dummy mapping and the URL you are using to invoke
it. I'm assuming the /* mapping is still present along with the dummy mapping.

As Costin is indicating by marking 3760 as a duplicate, perhaps it was the
restarting of Tomcat, not the dummy mapping itself, that is responsible for
the changing behavior in your test case.  I don't see the changing behavior,
but I may not be duplicating your test case exactly. As a result, we would need
to know your test case in exact detail.  Thanks.



DO NOT REPLY [Bug 3727] - Switched included request parameters

2001-09-23 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727

Switched included request parameters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||sebastian.kanthak@muehlheim.
   ||de



--- Additional Comments From [EMAIL PROTECTED]  2001-09-23 11:11 ---
*** Bug 3760 has been marked as a duplicate of this bug. ***



DO NOT REPLY [Bug 3727] - Switched included request parameters

2001-09-21 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727

Switched included request parameters





--- Additional Comments From [EMAIL PROTECTED]  2001-09-21 09:23 ---
But then, why do the values change, when we ADD a dummy url mapping (e.g.
'/foobar/*') in the test-application's web.xml file? Adding, another url mapping
shouldn't change the behavior of the servlet engine in this concrete case!
Did you run the sample code from above?



DO NOT REPLY [Bug 3727] - Switched included request parameters

2001-09-21 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727

Switched included request parameters





--- Additional Comments From [EMAIL PROTECTED]  2001-09-21 11:41 ---
All of your tests work for me.  That is that the servlet_path is empty and 
everything is in the path_info just like it should be.  The only way that I 
didn't get it was when I put a typo in the web.xml file by mistake, and Tomcat 
added the context anyway but without mappings.  While that might be considered 
a bug, the servlet_path and path_info were correct for the context 
configuration.



DO NOT REPLY [Bug 3727] - Switched included request parameters

2001-09-21 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727

Switched included request parameters





--- Additional Comments From [EMAIL PROTECTED]  2001-09-21 14:13 ---
Your remarks are corrct for the path_info and servet_path fields read from the
ServletContext object of a running servlet. In the case where the url mapping
'/*' matches, the servlet-path will be empty and the path_info will contain the
part after the context path up to the request parameters.

However, the problem I have reported concerns the path_info and servet_path
fields stored as request attributes after a servlet has been invoked by calling
the include method of a RequestDispatcher. The servlet is addressed by its class
name, thus the url mappings specified in the web.xml file are not involved in
this case. According to the specification of servlet api 2.2 / Section 8.3.1,
the request attribut fields of an included servlet contain the path by which it
was invoked and not the original request paths! Thus, for the example given
earlier the path_info should be 'null' and the servlet_path should hold the
value '/servlet/SnoopIncluderServlet'.

Could you please comment the second problem I have remarked: If you look at the
output of the given example code, why do the outputed values change, when a
dummy entry is ADDED to the current web.xml config?



DO NOT REPLY [Bug 3727] - Switched included request parameters

2001-09-21 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727

Switched included request parameters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2001-09-21 16:15 ---
I still thing the bug is invalid - /servlet/* is not part of the spec, is just a 
tomcat-specific thing ( well, all containers support that - but it's still outside of 
the spec). The attributes are set during mapping - and it works fine for all 'normal' 
mapps. 

I can probably fix this ( by changing Invoker to adjust the paths ), but it's low 
priority, and you shouldn't use /servlet mappings anyway ( they're only for backward 
compatibility with a feature that was never specified AFAIK )



DO NOT REPLY [Bug 3727] - Switched included request parameters

2001-09-21 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727

Switched included request parameters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2001-09-21 17:17 ---
Sorry to be so insistent, but for the area of servlet-based framework
development neither the given mapping nor the use of the include mechanism
are 'abnormal'. Any framework containing a central contoller servlet, which
handles all requests sent to the corresponding application context, has its url
mapping set to '/' and '/*'.

To push the problem back into the scope of the servlet API specification I have
modified the test code to call the servlet using its name. Thus, the call looks
like:

RequestDispatcher disp = null;
disp = getServletContext().getRequestDispatcher(/SnoopIncluder);

And, still, we get different results depending on the set of url mappings
present in the web.xml file. Having only '/' and '/*' defined the output
contains:

javax.servlet.include.path_info = /SnoopIncluder
javax.servlet.include.servlet_path = 
javax.servlet.include.context_path = /appsvtest
javax.servlet.include.request_uri = /appsvtest/SnoopIncluder

Adding a dummy url mapping, the values are set as it might be expected:  

javax.servlet.include.servlet_path = /SnoopIncluder
javax.servlet.include.context_path = /appsvtest
javax.servlet.include.request_uri = /appsvtest/SnoopIncluder

The example shows, that the problem has nothing to to with the Invoker. For me
this rather looks like a pattern matching problem for a given set of url
mappings and a request URI.



DO NOT REPLY [Bug 3727] - Switched included request parameters

2001-09-20 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3727

Switched included request parameters





--- Additional Comments From [EMAIL PROTECTED]  2001-09-20 17:53 ---
Since you have a servlet-mapping for /*, Tomcat's values are exactly what you 
would expect them to be.