tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yuri Kazakov <ykaza...@panache.co.jp>
Subject Re: JSP servlet for browser without cookie support
Date Mon, 19 Jun 2000 04:09:36 GMT


"Craig R. McClanahan" wrote:
> 
> Yuri Kazakov wrote:
> 
> > Alex Chaffee wrote:
> > >
> > > First, this sort of question belongs on tomcat-user, not tomcat-dev.
> > >
> > > Second, the way it's supposed to work is you have to explicitly call
> > > encodeURL on the URL strings.  Like so:
> > >
> > >  <a href="<%=response.encodeURL("/jobs/typist.html")%>">Typist</a>
> >
> >         This is not nasty?!
> >
> 
> A trivially simple custom tag implementation can do this encoding for you.  For
> example, usting the custom tag library in the Struts framework
> (http://jakarta.apache.org/struts), you would say:
> 
>     <struts:link href="/jobs/typist.html">Typist</struts:link>
> 
> to replace the above expression.  It renders an <a href="..."> tag, with the
> hyperlink suitably encoded only if necessary.
> 
> >
> > >
> > > The alternative would be to scan the whole page looking for URLs which
> > > is nasty and unreliable and slow.
> > >
> >
> > First, looking for URLs takes place only one time when JSP page is compiled
> > and only if session.isNew() or isRequestedSessionFromURL().
> >
> 
> This is not correct.  What matters is the state if the session (and URL rewriting)
> when the page is requested -- not when it is compiled.  Some servlet containers
> (including Tomcat's "jspc" capability) offer the ability to precompile your JSP
> pages, before there ever is a request.
> 
> Even if you really do compile when the page is first requested, that only detects
> the session state of the first requestor.  What happens if you request this page
> with cookies enabled, then I request it with cookies disabled?  The compile-time
> detection would get the wrong answer for me.
> 
> > During compilation JSP servlet spends most of time for file read/write/stat
> > operations, and I don't think that some simple URL logic will make it more slow.
> >
> > Second, JSP was designed to make HTML programming environment clean and simple
> > for the price of one JSP file compilation.
> > Now the strategy "access Internet from anything" (mobil phones, car navigators,
> > ..., even kitchen ware)
> > makes non-cookie access more and more intensive every day.
> > So I don't understand why old days requirement of automatic URL encoding
> > was removed from JSP specifications.
> >
> > What do developers think about this?
> >
> 
> In order to do the correct behavior under all circumstances, the JSP/servlet
> environment (why would you do this only for JSP pages?)  would have to scan the
> response as it is being created, looking for all the cases where a URL needing
> encoding would need to be replaced.  You would also need to buffer the output,
> because actually doing the encoding is going to change the content length -- and
> therefore invalidate any content length header that was set by the original JSP page
> or servlet.
> 
> Given the performance impact of the above, "thanks but no thanks" would be my
> personal response.

Yes, you are right.
But why don't do it simply.
Without any relation to requests and browsers JSP servlet always put 
";jsessionid=" + <% session.getId() %> to all URLs, when it compiles JSP.
It shouldn't make anything wrong, isn't it?
And almost no performance loss.

By the way servlet container is not so shy when it creates cookie,
even if it doesn't know, does browser support cookies or not.
But encodeURL() and encodeRedirectURL() include a lot of checks
and fail easily.
It looks for me developers don't like path included session IDs.
Why? What's wrong with them?

Sorry for disturbance, 
Yuri.

Mime
View raw message