- From: S. Mike Dierken <dierken@gmail.com>
- Date: Wed, 14 Jun 2006 20:15:16 -0700
- To: "'David Morris'" <dwm@xpasc.com>
- Cc: "'Julian Reschke'" <julian.reschke@gmx.de>, <ietf-http-wg@w3.org>
> > I disagree ... > > www is the protocol not the application. > > 'unsafe' is, as you say, an indicator of how data updates > might be handled. There is no fundamental unsafeness outside > of the context of the web server receiving the POST. Only > that server developer knows if there is any negative impact > of repeated use of POST and/or there is any other reason why > POST must be used. Unsafe merely means that the user agent > may not assume that repeating the post is safe. One way the > server developer can answer the question is to provide > javascript as part of the web content which repeats the post > without bugging the user because the web developer knows it is safe. > <pedantic>http is the protocol. WWW is the application that results from the use of that protocol</pedantic> > Only that server developer knows if there is any negative impact > of repeated use of POST and/or there is any other reason why > POST must be used. Actually, any client developer knows that POST is unsafe because the protocol specification says that it is unsafe (and also not repeatable). By the same token, all developers know that GET is safe and repeatable, PUT is unsafe but repeatable and DELETE is unsafe but repeatable. > Unsafe merely means that the user agent may not assume that repeating the post is safe. Unsafe means that the /first/ submission is not safe, not to mention repeated submissions. If you need to use POST and you want to ease the user experience in the face of resubmitting the request, then script trickery works as an enhancement but is not a general solution. Which isn't a big deal for nearly all web (page) applications.
Received on Thursday, 15 June 2006 03:15:22 UTC