Hi Len--
Netbeans has a HTTPMonitor that comes pre-packaged
If you look at messageID generation from Servlet doPost()
I would have Servlet DoGet() method implement the same MessageID generation
to uniquely identify each and every HTTP GET request
Documentation is available at
http://www.prescod.net/reliable_http.html
M--
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed. If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy. Thank you.
----- Original Message -----
From: "Len Popp" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <users@tomcat.apache.org>
Sent: Friday, April 06, 2007 1:26 PM
Subject: Re: [OT] GET-then-redirect 'reload' behavior
That's not the behaviour I'm seeing with Firefox 1.5 (I haven't tried
2.0).
I have a page that responds to a GET with a 302 redirect. The browser
then automatically GETs the redirect page, and the redirect URL is
shown in the address bar, and if I reload the page it re-GETs the
second page, not the original requested page.
Install the Live HTTP Headers extension for Firefox to see exactly
what your browser is sending and what the server is sending back.
--
Len
On 4/6/07, Christopher Schultz <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
I have many form handlers that redirect-after-POST so that executing a
RELOAD/REFRESH on the client side doesn't end up repeating the
transaction (and potentially creating two new database records, etc.).
I recently discovered that a redirect-after-GET does not offer this
protection. I have a link on one page that duplicates the current
record, then does a redirect to the "view record" page displaying the
new record. It appears that if I reload that resulting page, my browser
(Mozilla Firefox 2.0) resubmits the original request (to duplicate the
record), rather than the request that merely displays the new record.
I am not familiar enough with the HTTP specification to know whether
this is "correct" behavior or not, but the Mozilla folks typically make
attempts to follow specifications as closely as possible, so I am
reasonably confident that this isn't a bug.
Given that, is there a (simple) way to protect links against
resubmission similar to how a POST form might be protected? The only
thinks I can think of are to make the link into a POST form with a
button (which is kind of ugly) or to use a token that expires when the
link is followed (unless the original to-be-copied record page is
refreshed, in which case a new token is created).
Any other ideas or thoughts?
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGFngl9CaO5/Lv0PARAtINAJ0Vp7qW9sSsjgvpQkccQ6HF4JYYKACfXfXd
W6HYuYwGCeWFcj/bRjjoYwQ=
=0i7e
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
