The "must remain encoded" requirement for getRequestURI(), as was stated in the response by "lin" on the Macromedia forum thread, refers to any URL encoding that was done by the client to transmit characters like '/' and '&' in a URI. This doesn't address the question of whether session ids (which the servlet spec requires to be included as a "path parameter") should be striped or not.
The specs defining the syntax of URIs (RFC 2396) clearly identify things after a semicolon as "path parameters". What's not obvious is whether they should be considered part of the request URI or not. I would suggest that consistency with the way query string parameters are handled (they are stripped off) would be sufficient reasoning to conclude that path parameters should be removed as well. But it is not clear cut. It doesn't appear that there are any Watchdog tests for this particular scenario, and the same is likely true of the actual TCK. However, there is a presumtive comment at the begining of the servlet spec that is relevant: "A reference implementation (RI) has been made available which provides a behavioral benchmark for this specification. Where the specification leaves implementation of a particular feature open to interpretation, implementors may use the reference implementation as a model of how to carry out the intention of the specification." Tomcat, which is the basis of the RI for the servlet spec (the official RI is the J2EE reference implementaiton, which includes Tomcat code for the web container) has never, AFAIK, left the session id in the value returned by getRequestURI(), which implies (based on the paragraph quoted above) that this is indeed the intended behavior. The way to find out for sure is to ask for an interpretation from the servlet specification lead, Danny Coward <[EMAIL PROTECTED]>. As it happens, the topic of whether we should or should not strip path parameters was brought up to the JSR-154 (Servlet 2.4) expert group just last week, although not specifically referring to jsessionid parameters. I suspect a formal requirement (one way or the other) will end up getting put into Servlet 2.4. In the mean time, and in the absence of any interpretation by the spec lead, the behavior of the J2EE RI (which is identical to Tomcat's behavior in this respect because it uses Tomcat code for this) should be presumed to be correct. Craig McClanahan On Thu, 11 Jul 2002, Eddie Bush wrote: > Date: Thu, 11 Jul 2002 01:03:54 -0500 > From: Eddie Bush <[EMAIL PROTECTED]> > Reply-To: Tomcat Developers List <[EMAIL PROTECTED]> > To: Tomcat Developers List <[EMAIL PROTECTED]> > Subject: Re: getRequestURI() > > Look at what Bob posted. I'd listen to the spec before I listened to > anyone else - hold that up to their nose. It's black and white. > > Alex Kachanov wrote: > > >-----Original Message----- > >From: Eddie Bush [mailto:[EMAIL PROTECTED]] > >To: Tomcat Developers List > >Subject: Re: getRequestURI() > > > >>>Ah - now I feel stupid. I was thinking he was saying encodeURL didn't > >>>put it there. According to what your interpretation is he things > >>>getRequestURI doesn't get it back. :-/ > >>> > > > >No, I tell that getRequestURI in Tomcat returns file name only - and I'm FINE with >that. > > > >While, in JRun getRequestURI returns file name + jsessionid - and I'm not FINE >with that. > > > >Macromedia support tells that Jrun behavior is according to the specification, and > >that all other AS are wrong and JRun is right in this particular case. > > > >Then, who IS right? > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
