--
Dan Cornell wrote:
> --
>
> > > If anyone is interested, I could probably get that code out under the
> > > GPL or something along those lines. I'll warn you that the code isn't
> > > exactly pretty, and it isn't exactly fast, and the architecture is kinda
> > > funky, but if someone has the time they could probably clean it up and
> > > include it into JServ as part of the actual implementation of the
> > > session maintenance part of the Servlet API. I would love to do this
> > > but just don't have the time right now...
> >
> > Since that isn't part of the api, it probably wouldn't go there. ;-) but, if
> > you want to donate it to the jserv_utils cvs tree that would be cool. Of
> > course GPL isn't welcome around here, so it would have to be under the Java
> > Apache style license.
>
> The API allows you access to the mechanics of session maintenance via
> methods like HttpServletRequest's isRequestedSessionIdFromUrl(). I
> haven't been through all of the JServ code, so my understanding could be
> flawed, but right now I think JServ's state maintenance infrastructure
> will _receive_ session information from either the URL or a cookie, but
> will only automatically _send_ session information in cookies. Hence
> the requirement that you manually call "encodeUrl" in your servlet
> output.
>
Apache JServ conforms to the servlet API with respect to session state
management. Manually calling encodeUrl() or encodeRedirectUrl() is required on
*all* servlet engines if you wish to support sessions where cookies might not be
enabled.
The reason that manual encoding is required is that the servlet engine does not,
as a general rule, look at the output that is being generated. It's purpose is
to simply write the bytes out as fast as it can. Thus, it is up to the developer
to call the encode method when he or she knows that a URL is being generated.
>
> My point is that you could probably glue this into JServ in such a way
> that it would dynamically select URL or cookies (or be set in a config
> property...) for session maintenance. Don't necessarily know how
> helpful this is, or that this is even desirable, but it has served us
> pretty well for a couple of different applications.
>
You could indeed include this kind of code in Apache JServ so that it always
happened, but this would have the following ramifications:
* You would be creating a non-standard, non-portable feature.
Anyone who relied on this behavior as "normal" would be in for
a very rude shock when they try to port their servlets to a
different servlet engine. You'd be amazed at how many people
have never read the servlet API spec, so they just assume that
everything in whatever servlet engine they are using is
"standard".
* You have to be smart about when you do this kind of filtering
(i.e. only if the content type has been set to "text/html"). You
certainly don't want to encode a sequence in the middle of a
dynamically generated GIF image that just happens to look like
a hyperlink :-).
* You would have to pay a performance penalty -- thus, you'd want
this to be an optional feature, disabled by default.
>
> Also, I haven't looked at it yet, but I don't imagine anyone around here
> will have any problems with the Apache style license. I'll poke through
> the code, clean it up a bit, and pull out what is relevant.
>
I think it would be cool to provide a parsing/encoding library like you are
talking about as an add-on. It would be easy to plug it in to a special
file-serving servlet, for example, so that the performance price was paid only
when you were sending "static" HTML files that were created separately.
>
> Thanks,
>
> Dan
>
Craig McClanahan
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
READ THE FAQ!!!! <http://java.apache.org/faq/>
Archives and Other: <http://java.apache.org/main/mail.html/>
Problems?: [EMAIL PROTECTED]
