I think you're on target, and I've done the same thing in various
applications. There are cases where this particular security model falls
short, but if you're going to have a single servlet deal with multiple
functions (and for many apps this is a very good idea) this is the way to
do it. It also makes it easier to integrate various kinds of dynamic
content into a public web server. On a content site, for instance:
http://content.com/servlet/topicsServlet?topic=computers
versus
http://content.com/servlet/topicServlet/computers
The latter will be indexed by search engines. The former often won't, as it
has CGI style parameters in the URL. You can further encode multiple
levels of information this way.
Once thing to keep in mind is that the getPathInfo() method, along with
some of the related methods (getPathTranslated() and so forth) aren't
always implemented in a consistent way. At one point we discovered that the
JWS implementation and the servlet spec were at odds with each other on how
this information was passed back to the servlet. I can't remember which one
got changed.
Will
At 04:33 PM 6/23/2000 -0400, you wrote:
> In this same vein, I was interested in some feedback from my
>fellow developers. Often the parameters include not only data for the
>transaction, but function as well. In other words, it describes not only
>what to operate on, but also what the function requested is. This is
>often true when one servlet takes care of many functions.
>
> What I have found, esp. when I was doing a lot of CGI, is that by
>using the "extra path info", I was able to capture funtion well, and was
>able to control funtion using the servers native security.
>
> In other words, instead of:
>
> http://myhost/servlet/bankstuff?func=transfer&amount=1000.00
>
> you can use:
> http://myhost/servlet/bankstuff/transfer?amount=1000.00
>
> Small difference? Yes, _but_, now the server's ACLs can be used to
>control funtion. (Maybe you have access to bankstuff/balance, but not
>bankstuff/withdraw.) Also, you have a clear seperation of function from
>data. Bookmarks also become easier to handle -- I think that it is closer
>to the original intent of the URL design.
>
> So, I was wondering what the rest of you thought, and how you
>design this part of your applications. I don't remember seeing any
>discussion of the HttpServletRequest.getPathInfo() method. Hmm?
>
>
>On Thu, 22 Jun 2000, Jarec Basham wrote:
>
> > Think of POST like the browser opening an OutputStream and the server
> > opening an InputStream. The form data is just sent as a byte feed and then
> > reinterpretted by the server. This means that the data size is effectively
> > unlimited. You don't have to worry about this as your servlet is talking to
> > the server and will get the reconstructed data. Monitoring the requests
> > will most likely just show you the HTTP header which is all text based.
> When
> > you use doPost in your servlet it knows to look a biot deeper in the server
> > to get the parameters. The end result from the server side is much the
> same,
> > you just read in the parameters.
> >
> > GET on the other hand is just a simple text string and has a limit of 254
> > characters/bytes. Anyone who can trap your HTTP header can read this.
> >
> > Also I would recomend not using GET if you want to guarantee that the page
> > gets refreshed. It is too easy for people to cut and paste URL with
> > parameters intact when you use GET.
> >
> > Jarec
> >
> > --------------------------------------------------
> >
> > Hi Jarec,
> >
> > Thanks for your reply,
> >
> > Streaming of data means? How is it done or achieved?
> > Will the entire form data sent to the server?
> >
> > Cause I have created a simple web server to monitor the requests from
> > browser,
> > So when I used it to monitor the request, I was surprised to see there was
> > no
> > form data passed back to the server. Can you tell me how this is achieved?
> >
> > I also heard that for large data, it's advisable to use POST rather than
> > GET why is
> > it so?
> >
> > With Regards,
> > Vivin.
> >
>
>___________________________________________________________________________
>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
---
William Crawford + 01 617 577 7844
Invantage, Inc [EMAIL PROTECTED]
___________________________________________________________________________
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
