> On Tue, 29 Aug 2000, Victor Hadianto wrote:
> > > >Isn't that interesting? I always thought that the doGet() will be
> > > >called instead if the user click on the 'refresh' button.
> > > No, it just repeats the previous command
> > I don't now about other people opinion, but I really think it's
> > better when the browser 'Refresh' button just fetch whatever link [...]
>
> This is standard browser/HTTP behavior, it's got nothing to do with
> servlets.
Correct. I grow more and more convinced that most of the posts
on this and related lists need to read the specs and RFCs for HTTP and
associated technologies before starting in on actual programming.
> Maybe from a servlet-developer point of view this might seem odd
> (and problematic) to you, but I think to most web users (and there
> are a lot more of them than us :-), it is the right behavior.
Yup; the thing that torques me off is that browsers are very
inconsistent about the behavior. It is flat-out impossible with some
browsers to keep a form from being re-POSTed. I finally, after months
of returning to the well and countless hours of painstaking,
frustrating exploration and testing, found a reliable, broadly
compatible (NS3, NS4, NS4.5, IE3, IE4, IE5) way to fake it with
Javascript and multiple frames.
> Now, in the servlet, there are ways to detect this and handle it
> differently. (Actually, I'm not sure there is a way to specifically
> detect a "Refresh"/"Reload", but you can detect a repeat request,
> which is similar, and may be sufficient.)
Possibly check the referrer headers. In general, for debugging
and trouble-shooting this kind of thing, I found it immensely helpful
to use a simple proxy server that showed me exactly what strings the
browser was sending to the server and vice versa.
> > Actually now that I think about it, I really am not sure how do the
> > servlet engine handle the parameter in doPost() from the
> > form. Transparent as it is from the serlvet programmer, it really
> > helps to understand the nitty gritty of servlet.
>
> The "posted" part of the request must be parsed, and the parameters
> extracted. There is a helper function in HttpUtils.java,
> parsePostData(), to do this. But I believe most servlet containers do
> this for you automatically on a POST (perhaps depending on the mime
> type).
From my dim recollections of reading in the past, refreshed by my
recent reading of the 2.3 servlet spec draft, the servlet container
will parse the input stream when you first request parameters, but
will hold the input stream ready for direct access until that point.
> So in that sense whether it was a POST or a GET is transparent to
> the servlet -- either way the parameters will be accessible the same
> way, via getParameter() et al.
And in fact you can do both - the container will stack the
values. I'm not entirely sure I like that.
Steven J. Owens
[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
