I would also disagree with including cookies, but how about path parameters
as defined in RFC2396?
Example
/servlet/servleta/extra/path;pathparam?querystring=12345
Our soon-to-be-released server uses them for Session URL re-writing. We
strip them off and place the value in the PATH_PARAMS attribute before doing
any resource mapping.
While were on this subject, if you nest a servlet with RequestDispatcher,
what should happen with any query string passed in the getRequestDispatcher
method?
Say the original request was '/servlet/servleta?aaa=123' and servleta
'included' servletb with the request '/servlet/servletb?bbb=567'. What
should servletb get from getQueryString(), getAttribute("QUERY_STRING"), or
getParameterNames()?
George
-----Original Message-----
From: A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of Craig
R. McClanahan
Sent: Thursday, April 22, 1999 9:44 AM
To: [EMAIL PROTECTED]
Subject: Re: getParameter() merging redux
Cezar Totth wrote:
> Hi, I think Carlos is right here.
> Cookies are also limited in total number and a much smaller limit (20)
> for a given server, and browsers should silently strip them off.
> Someone should not operate intensively on cookies.
> Otherwise will invite to ... well... "cookie abuse" when a few
> servlets (let say 5) set each 5 cookies, the older 5 are silently cut
> off by browser, an every servlet gets confused why it is not getting them
> back..
>
> It is safer to keep cookies within the servlet-engine, web-server or
> app-server kitchen, not to encourage developers using them for each
possible
> application-level variable that can be kept more efficiently in session.
>
> Cezar.
>
> On Thu, 22 Apr 1999, Carlos Amengual wrote:
>
> > I disagree to include cookies, as this breaks the "domain barrier"
> > between cookies and parameters, so it could break existing code:
> >
> > 1) There may be code that relies on the list of parameters as provided
> > by the API, and would get confused by extra parameters.
> >
> > 2) A cookie parameter set months ago (possibly by someone else) could
> > inadvertently have the same name as a form parameter. You may get false
> > not-nulls, etc.
> >
> > 3) In general, an application could be interfered by cookies set for
> > another appl. but that got sent to the same domain, host, or tree.
> >
> >
> > Carlos
> >
> >
> > jon * wrote:
> > >
> > > I vote that it should be GPC (get/post/cookies) by default and it
should
> > > also be configurable on a per/request (ie: local) basis.
> >
I share the opinion expressed by Carlos and Cezar that cookies should *not*
be
included in the results returned by getParameter(), for the reasons they
expressed and one more -- there is already a nice, unambiguous way to
retrieve
the value of any cookie that was included (HttpServletRequest.getCookie()),
so
including those values as parameters as well would be redundant.
If Jon's suggestion of a configurable priority order is taken, I would
suggest
that configurability be done on a per ServletContext basis rather than
globally
-- different applications running on the same web server might wish to apply
different rules.
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
