You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ryan Dewell <ry...@dewell.org> on 2004/02/18 16:52:26 UTC
WebdavServlet Locking Issues
Hello,
I've been testing the WebdavServlet that comes packaged with Tomcat 5.0.18 and am impressed by its simplicity (and by its possibility for extensibility using DirContext).
I've run into some problems, however, with getting its locking functionality to work with client apps. I've tried several webdav clients including Dreamweaver MX, and none of them seem to like the way that the WebdavServlet implements locking. In particular, once the client obtains a lock (which occurs successfully), it is not possible for the client to perform any other operations on that resource -- not even unlocking the resource is possible. Any attempts at accessing the resource, and the client is sent an SC_LOCKED status by the WebdavServlet.
I read a few archived posts from the 2001/2002 timeframe that reference some locking issues, but I'd be suprised that 2 years later no one has gotten locking to work with apps like Dreamweaver?
Any suggestions or workarounds are welcome!
Thanks,
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RE: Stopping repeating requests
Posted by Peter Guyatt <pg...@telesoft-technologies.com>.
Hi All,
Thanks for the replys.
The form is processed by my servlet and the user is directed to another page
(in this case a summary list of all of the data that they have entered).
The problem occurrs when they hit refresh on this summary page and the last
action was to add a new entry to there database, it looks like it is because
the URL still has the last request in it.
Is there any way of clearing this URL other than useing window.location.href
?
The unique token sounds like a good idea.
Thanks
Pete
-----Original Message-----
From: Parsons Technical Services [mailto:parsonstechnical@earthlink.net]
Sent: 18 February 2004 18:14
To: Tomcat Users List
Subject: Re: Stopping repeating requests
Phil,
True. I should have not said "all client side". How about client side
validation?
Point being as weather to handle it more from the client or server. All
depends on application.
Doug
> Hi!
>
> Parsons Technical Services wrote:
> > The
> > better way is to clear the form or send them to another page. That's all
> > client side.
>
> Not necessarily. What I do in such situations is this: have a servlet
> process the form data and then send something else (e.g. an "update
> successfull"-page) as response via sendRedirect(). This way, the user
> _has_ to at least push the back button. If you then add headers to
> prevent the page containing the form from being cached, even that
> would give the user a plain empty form all over again.
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Stopping repeating requests
Posted by Parsons Technical Services <pa...@earthlink.net>.
Phil,
True. I should have not said "all client side". How about client side
validation?
Point being as weather to handle it more from the client or server. All
depends on application.
Doug
> Hi!
>
> Parsons Technical Services wrote:
> > The
> > better way is to clear the form or send them to another page. That's all
> > client side.
>
> Not necessarily. What I do in such situations is this: have a servlet
> process the form data and then send something else (e.g. an "update
> successfull"-page) as response via sendRedirect(). This way, the user
> _has_ to at least push the back button. If you then add headers to
> prevent the page containing the form from being cached, even that
> would give the user a plain empty form all over again.
>
> Phil
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Stopping repeating requests
Posted by Philipp Taprogge <Ph...@gmx.net>.
Hi!
Parsons Technical Services wrote:
> The
> better way is to clear the form or send them to another page. That's all
> client side.
Not necessarily. What I do in such situations is this: have a servlet
process the form data and then send something else (e.g. an "update
successfull"-page) as response via sendRedirect(). This way, the user
_has_ to at least push the back button. If you then add headers to
prevent the page containing the form from being cached, even that
would give the user a plain empty form all over again.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Stopping repeating requests
Posted by Parsons Technical Services <pa...@earthlink.net>.
Pete,
When the user submits the page where is the user sent?
If he stays on the same page and the form stay populated you need to do some
checks for change in a field before allowing the page to submit again. The
better way is to clear the form or send them to another page. That's all
client side.
On the server side:
Is there a positive ID field such as SSN that can be picked up from the
form?
If so then test the database for existence of this and inform the user. Or
(I haven't done this yet but am sure it will work) grab the session ID and
set a flag or a cookie that is checked prior to updating the database. You
could even give the user the option to resubmit the data and do an update
with it overwriting the prior entry.
If you can use some unique data from the form this is usually the better
(IMHO). Some other factor to consider in which approach to take is if the
client fills in the form say one or two days later or from another machine.
Doug
www.parsonstechnical.com
Subject: Stopping repeating requests
> Hi,
>
> I have a problem where a user enters data into a form and then submits
this
> to the server, which in turn wrights this content into a database.
>
> The problem I have is that if the user then refreshes the page via F5 then
> it adds the same data in again.
>
> Is there any way to ensure that this does not occur.
>
> Any help would be greatly appreciated.
>
> Thanks
>
> Pete
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Stopping repeating requests
Posted by Philipp Taprogge <Ph...@gmx.net>.
Hi!
Peter Guyatt wrote:
> I have a problem where a user enters data into a form and then submits this
> to the server, which in turn wrights this content into a database.
>
> The problem I have is that if the user then refreshes the page via F5 then
> it adds the same data in again.
>
> Is there any way to ensure that this does not occur.
Not really... to your servlet/jsp processing the HTTP-POST, those two
requests are two separate entities that each need to be processed. How
should your servlet know if the second request is a reload or another
person POSTing from the same machine as the first one?
If you have any criteria in the data itself, you could, of course, add
some kind of logic to the servlet in order to validate the data first.
If, for example, you d not want two database rows that are entirely
identical, you could first SELECT the form data and only INSERT if
there is no result.
HTH
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Stopping repeating requests
Posted by Harry Mantheakis <ha...@mantheakis.freeserve.co.uk>.
I use a system where a servlet sets a 'token' (a random number attribute)
which the JSP must return (using a hidden form field attribute) to the
servlet when the form is submitted.
The servlet keeps a copy of the token. The servlet checks the token sent by
the JSP with its own (current) copy. If the two match, the form is
processed, otherwise it is rejected.
When the servlet processes a form-submit request, it always discards the
current token, so that it can never be reused.
It means, of course, that you have to design things so that the same
'controller' servlet is used to both display the JSP (after it sets the
token) and then to handle the form submit from it.
It works for me.
Harry Mantheakis
London, UK
> Hi,
>
> I have a problem where a user enters data into a form and then submits this
> to the server, which in turn wrights this content into a database.
>
> The problem I have is that if the user then refreshes the page via F5 then
> it adds the same data in again.
>
> Is there any way to ensure that this does not occur.
>
> Any help would be greatly appreciated.
>
> Thanks
>
> Pete
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Stopping repeating requests
Posted by Peter Guyatt <pg...@telesoft-technologies.com>.
Hi,
I have a problem where a user enters data into a form and then submits this
to the server, which in turn wrights this content into a database.
The problem I have is that if the user then refreshes the page via F5 then
it adds the same data in again.
Is there any way to ensure that this does not occur.
Any help would be greatly appreciated.
Thanks
Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: WebdavServlet Locking Issues
Posted by Remy Maucherat <re...@jboss.org>.
Ryan Dewell wrote:
> Hello,
>
> I've been testing the WebdavServlet that comes packaged with Tomcat
> 5.0.18 and am impressed by its simplicity (and by its possibility for
> extensibility using DirContext).
>
> I've run into some problems, however, with getting its locking
> functionality to work with client apps. I've tried several webdav
> clients including Dreamweaver MX, and none of them seem to like the
> way that the WebdavServlet implements locking. In particular, once
> the client obtains a lock (which occurs successfully), it is not
> possible for the client to perform any other operations on that
> resource -- not even unlocking the resource is possible. Any
> attempts at accessing the resource, and the client is sent an
> SC_LOCKED status by the WebdavServlet.
>
> I read a few archived posts from the 2001/2002 timeframe that
> reference some locking issues, but I'd be suprised that 2 years later
> no one has gotten locking to work with apps like Dreamweaver?
>
> Any suggestions or workarounds are welcome!
The WebDAV servlet has only recently become maintained again.
There are some related patches in Tomcat 5.0.19, although I don't know
if this would fix your problems.
--
xxxxxxxxxxxxxxxxxxxxxxxxx
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
xxxxxxxxxxxxxxxxxxxxxxxxx
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org