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
