Somebody asked:
> Is it possible to invoke the doPost() method (instead of the doGet()) of the
> servlet to which I am redirecting using response.sendRedirect() ??
No.
As far as I've been able to find (and believe me, I've looked) it
is not possible for the server to have the browser rePOST. If anybody
has figured out how to do this, I'd appreciate a clue. A friend once
explained the whys and hows of it to me in great detail, I'll append
an excerpt from his message at the end of this post. So far, the only
way I've found is to simulate it, having the servlet generate a page
containing custom javascript.
I suppose it could be done using a java applet, although the
applet would be limited in which servers it could communicate with.
Speaking of that limitation, what're the implications of having two
different servers (different boxes, ip numbers, etc) with the same
root domain? e.g. a user gets an applet from bar.foo.com, can the
applet communicate with baz.foo.com? Or if the user gets an applet
from just foo.com, can it communicate with baz.foo.com?
Here're my friend's comments on the matter:
----------------------------------------------------------------------
The browser and server communicate using HTTP, and HTTP inherits
a lot of its structure from MIME. to get a second POST from
the browser, you'd have to violate the encapsulation of the MIME
entities which make up an HTTP transaction, and browsers just
don't do that.
MIME entities come in two basic flavors: single-line, and
multiline. the bulk of any HTTP message between a browser and
a server will be a sequence of single-line entities. the
messages which originate from the server only allow a single
multi-line entity, in fact.
the general structure of an HTTP server message is:
Server-type: whatever \
Date: whenever | single-line entities
Estamp: transaction ID string /
Content-type: text/html \
|
SGML declaration | multiline entity
HTML document /
where the structure of a generic single-line MIME entity is:
name: value
and the complete structure of a multiline MIME entity is:
Content-type: MIME type declaration
additional parameters
DATA
sentinel
HTTP normally limits a message to a single multiline entity, so
it cuts some corners to reduce overhead. both the field for
additional parameters and the sentinel (which is just a string
that lets the receiver know the data is done) are eliminated.
the field for additional parameters is where you'd normally put
the name of the information to follow, but since there's only
one multiline field, giving it a name would be a waste of time.
likewise, the webpage itself has a structure which lets you
know when it's finished, so adding another "yes, it's really
done" string would be redundant.
the structure of a browser request is more or less the same as a
server message, but it's prefixed with a single line that lists
the request method, the name of the file to be processed, and
the specific version of HTTP which will be used:
GET http://www.foo.com/index.html HTTP/1.0
for instance.
the GET method only supports the addition of single-line MIME
entities, so the general structure of a GET request is like so:
GET http://www.foo.com/index.html HTTP/1.0
User-agent: browser ID string
Date: whenever
HTTP-referrer: last page visited
in the case of a GET request with additional information tacked
on as a script parameter:
<a href="http://www.foo.com/script.pl?data">click</a>
the request would look like so:
GET http://www.foo.com/script.pl HTTP/1.0
User-agent: browser ID string
Date: whenever
Content-length: 4
Query-string: data
there's a maximum limit to the length of a single-line MIME
entity, because the C command which reads to the end of a line,
fgets(), takes a parameter which sets an upper limit on the line
length. there used to be a command which didn't take a limit,
but it tended to cause buffer overruns when told to read a line
that didn't have a return character at the end. that's what
made the Great Internet Worm possible, and now everyone uses
fgets(). usually, each application-level protocol will set its
own upper limit for the acceptable length on a line.
the POST method bypasses the line-length restriction by sending
its data as a multiline MIME entity. the structure of a
generic POST request would look like so:
POST http://www.foo.com/script.pl HTTP/1.0
User-agent: browser ID string
Date: whenever
Content-length: 10
Content-type: text/x-encoded
name=value
raw HTTP doesn't support reflected POST requests, because the
multiline entities used in browser and server messages overlap.
what you want is a server message that looks like so:
Repost-to: new URL
Content-length: 10
Content-type: text/x-encoded
name=value
which the browser would use to assemble a new POST query.
that's certainly possible in theory, but it's not part of HTTP
as it curently exists.
that being the case, a second POST must be explicitly
constructed by the browser. again, in theory, Java and
Javascript should be able to do that. unfortunately, i believe
that both Javascript and the JVM place restrictions on the
ability to make new network connections. the only machine
you're able to make a connection to, if memory serves, is the
one from which you got the current page.
it's a security issue. there are countless awful things that
could be done if servers are allowed to share, and possibly
hijack, data among themselves. for cluelessness on that scale,
you'd have to try VB or directX.. after all, they're produced by
the same company who gave us Outlook (IMHO, the next version
should be called "LookOut!") and by proxy, Melissa.
----------------------------------------------------------------------
Steven J. Owens
[EMAIL PROTECTED]
[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
