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=8099>. 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=8099 DefaultServlet looses query string information in redirect [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2002-04-16 07:14 ------- First thanks for your quick reply. Why is my query string not URL encoded ? RFC 1738 states: "Thus, only alphanumerics, the special characters "$-_.+!*'(),", and reserved characters used for their reserved purposes may be used unencoded within a URL." The query string "?20" only contains alphanumerics and a reserved character so it is already URL encoded. The HTTP/1.1 specification simply states a query string as: query = *( uchar | reserved ) I could nowhere find a reference where it is stated that the query string must be of type: param1=attr1&...¶mN=attrN Let me explain why this is a serious problem for us. We are devloping a web content mangement system which is running a quite a few sites by now. In our system you can access a web page directly py typing http://servername/?id where id is the id of the web page (called an entry in our system). Our users are used to this and there are also a lot of URLs public which use this. So there is no way to change this for us at the moment. Apache Web Server with the old JServ handles this fine and also customers running eg. ServletExec have no problems. So the only workarounds for us at the moment is to run Tomcat with Apache which does also the job but we would like to go with simply Tomcat because of an easier configuration. The second solution is to patch Tomcat which works fine, but we don't want to do this with every Tomcat update. If you can convince me that there is a spec somewhere which states that the query string is wrong I will shut up ;-) But this is really a blocker for us. Thanks for your help. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
