I think I agree with all of this. For JSTL 1.0, we opted to be a bit conservative since the need didn't yet strongly present itself. It wouldn't surprise me if a future version can add support for headers and HTTP POST; that might represent the knee in the curve, so to speak, between convenience and encumbrance.
-- Shawn Bayern "JSTL in Action" http://www.jstlbook.com On Wed, 21 Aug 2002, peter lin wrote: > I'm not sure where it should reside to be honest. I can see argument for > both sides. If I wanted to access data that resides on an IIS machine > that has challenge/response turned on, it would be good to have > cookie/auth support in jstl <c:import> but one could easily argue it > should be in a bean to provide more advanced capabilities like caching > or other RPC protocols. > > For an enterprise solution with high loads, it might make more sense to > create a custom solution, but I've seen situations where data comes from > third parties. Trying to get data providers to build a custom RPC > mechanism often is more trouble than it's worth, so a simple <c:import> > mechanism that supports cookies & authentication would be a simpler > solution. > > I'm glad the decision isn't up to me because either way you go, some one > is going to complain. > > peter > > > Shawn Bayern wrote: > > > > On Wed, 21 Aug 2002, peter lin wrote: > > > > > in the interest of discussion. I find it useful to have cookie, > > > user-agent and other advanced capabilities in a web services context. > > > As web services becomes more common place, supporting those features > > > might become very important. > > > > But is it important to support this from within JSP pages, instead of > > Java-based components? > > > > -- > > Shawn Bayern > > "JSTL in Action" http://www.jstlbook.com > > > > -- > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
