>>> Jay Burgess <[EMAIL PROTECTED]> 01-Feb-01 7:57:55 PM >>>
>I believe I read somewhere that our new server uses
>JSDK 2.1, in which the RequestDispatcher was introduced,
> but again I'm unclear about the implications.
>I really have no idea how their SSI processing is done, whether
>it's another servlet (like Apache JSSI), or something else.
>I just assumed that if the original request TO the web server
>FROM the client browser was for an .SHTML page (note
>the "S"), AND that request for that page included query
>string information, then that query string info should be
>propagated from the web server to the SSI processor to my
>servlet, and then be available with getQueryString().
You're assumption is not necssarily correct.
The SSI is probably being done with a RequestDispatcher.forward from
the SSI processor to your servlet.
What the SSI servlet will do is scan the page for the <servlet> token
and then form a RequestDispatcher instance to call your servlet.
So this:
<servlet path="/myservlet?arg1=val1&arg2=val2">
<param arg3="val3">
</servlet>
will get converted to this:
RequestDispatcher rd=
getRequestDispatcher("/myservlet?arg1=val1&arg2=val2&arg3=val3");
The spec is *unclear* about what the semantics are when a path
parameter overrides a path parameter specifier. The spec is *unclear*
about this because the <servlet> tag is not part of the servlet
standard.
Note that the JSP standard has slightly different semantic for a very
similar tool. In JSP you can use:
<jsp:forward page="/myservlet?arg1=val1">
<jsp:param arg1="val3"/>
</jsp:forward>
to forward a request to another location. The JSP spec says that the
recieving page should get the query looking like this:
?arg1=val3,val1
Thus there are multiple values for the parameter (which you can
access using the request call: String[] getParameterValues()) but the
specifier takes precedence.
But it looks like your vendor has simply chosen to make the specifier
replace whatever value is found in the parameter path. My humble
opinion is that your vendor's SSI servlet *should* mimic this JSP
behaviour and that would solve your problem.
However there are some other possibilities:
1. get your vendor to provide a switch for the SSI servlet to make it
do precedance the other way (the way you want)
2. use an alternative SSI servlet with your existing vendor's servlet
engine (SSI servlets are fairly simple and should just plug in - note
that the Apache Jserv one is unlikely to work unfortunately).
3. use a different vendor (yours doesn't sound very sympathetic or
clued up)
BTW: you haven't missed anything about POST. Duane was mistaken about
your circumatances.
Nic
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
