tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: JSP servlet for browser without cookie support
Date Mon, 19 Jun 2000 03:17:44 GMT
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
(, 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.

> Tomcat user.

Craig McClanahan

View raw message