Enhydra and the PathInfo request variable

This e-mail is intented to describe, (and propose a correction to) a 
bug/feature in Enhydra's Presentation Layer whih prevents the use of the 
PathiInfo variable in a presentation Object. It is sent to the Enhydra 
core developpers in order to have their opinion regarding that matter. 
Thanks for reading this rather long bug report, and have an opinion on 
it....


 What's this PathInfo stuff

Back in the old days of CGIs, the PATH_INFO variable was defined like 
this :

   * PATH_INFO : The extra path information, as given by the client. In
     other words, scripts can be accessed by their virtual pathname,
     followed by extra information at the end of this path. The extra
     information is sent as PATH_INFO. This information should be
     decoded by the server if it comes from a URL before it is passed
     to the CGI script.

So if a URL was : 
http://www.myserver.tld/cgi-bin/script.pl*/path/to/file.c*?var1=3&var2=4

The extra bit of the url after the CGI script name and before the 
QUERY_STRING was made available to the script via the environment 
variable PATH_INFO

The use of this variable was for example to implement filters on a 
hierarchy of files : the script would do its job (ex. syntax-higlighting 
of /path/to/file.c), then return the modified file to the client.


 Enhydra's handling of the PathInfo variable

According to Enhydra's (and Servlet's) specification, any PO can access 
the PathInfo variable, through the HttpPresentationRequest object 
present in the comms.request member variable, passed via the Servlet 
Engine.

Alas, any attempt to use use a URL like : 
http://www.myserver.tld/prefix/package/my.po*/path/to/file.c* fails with 
the exception :

com.lutris.appserver.server.httpPresentation.FilePresentationException:  
  File /prefix/package/my.po/path/to/file.c not found on application class path 

But if you put some debug information in your 
application.requestPreprocessor(comms) method, you realize :

  1. the PathInfo variable is correctly set
     (comms.request.getPathInfo() returns /path/to/file.c
  2. comms.request.getPresentationObjectPath() returns
     /prefix/package/my.po, so we expect this PO to be called...
  3. comms.request.getPresentationObjectRelativePath() returns
     /package/my.po/path/to/file.c

Since this is the latter method getPresentationObjectRelativePath() that 
is used in the HttpPresentationManager Run() to find the correct PO 
class to run, we do suspect this method to be somewhat the source of our 
troubles...

the Enhydra's API states :

java.lang.String getPresentationObjectRelativePath() 
  Returns the part of the request URI after the presentation manager servlet, upto and  
  including the presentation object .po, but not any path info. 

So here it should return */package/my.po*, which is not the case.

I digged into the source (and the enhydra mailing-list...), and realized 
that there was a problem connex to mine, regarding the way Enhydra 
encodes the session ID in the URL (if the conf. variable 
SessionManager.SessionEncodeUrlState is set to "Always" or "Auto")

I personaly never uses the URL session encoding stuff, but I guess this 
way of maintaining the link between a session and a client interferes 
with the using of the PathInfo variable : the session id is stored in 
the PathInfo variable , like this

comms.request.getPathInfo() returns 
;jsessionid=yFOGaaPGtlTEfssazfw12qcF(fwAAAR_Q)

So there are two flows in Enhydra design/coding regarding that matter :

  1. the request.getPresentationObjectRelativePath() does not return
     the correct information, thus leading to an error if you use a
     PathInfo in your PO URL
  2. the session state should not be stored in the "technical" PathInfo
     variable, since the current implementation prevents the use of
     this variable for any other purpose.


 Solution(s)

IMHO, the use of PathInfo should not be used to store the session ID : 
(1) it should be placed into a "GET variable" into the QUERY_STRING, or 
at least (2) Session URL encoding should not prevent the use of the 
PathInfo by the enhydra application. Since the solution (1) would lead 
to a major change to Enhydra's code, I would rather prefer the solution 
(2) :

The general idea is to still use the PathInfo variable to store the 
Session ID (if configured to do so), but to allow its use to store 
something else BEFORE the jsessionid stuff, like this :

http://www.myserver.tld/prefix/package/my.po*/path/to/file.c*;jsessionid=XXXXXXXXXXXXXXX?var1=3&var2=to

   * Modify request.getPresentationObjectRelativePath() to return what
     it should
   * Modify StandardAppUtil.getRequestSession(comms) : it is here that
     the PathInfo variable is used to find the session ID (if
     configured to do so). this method should be made compatible with
     the use of user information before the ";jsessionid=XXXXX" in
     PathInfo
   * add a getCleanPathInfo() method to HttpPresentationRequest
     interface, which returns the "useful" PathInfo, without the
     jsessionid stuff
   * test this against Enhydra director : I had a look into the code
     which deals with the jsessionid parameter (edir_parse_uri() in
     edir_string.c), and it should support this extension (NOT tested)...

Before going any further and code it myself, I would like to have the 
opinion of you, fellow enhydra developers, especially from the people at 
"Together TeamLösungen"...

--
Frederic Garzon  <Frederic.Garzon@xxxxxxxx>
---------------------------------------------
  o              51, rue de Verdun
 /      _ __ _   92158 Suresnes cedex
/ /\  /_  / /_   France
\/  \/_  / /_/   Tel. +33 (0) 1 41 44 85 45
 Inetsys S.A.    Fax  +33 (0) 1 46 97 20 10