W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2006

RE: Extension methods & XMLHttpRequest

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>
Message-ID: <4490d0bf.5fe6c53f.0130.0590@mx.gmail.com>


 
> 
> 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:44 GMT