RE: Question about section 9.3 of APP

[Yaron Goland <yarong@xxxxxxxxxxxxx>]

Joe/James - HTTP clearly defines that the user is responsible for any and all actions they initiate with unsafe methods. This is no different than a user buying a buggy piece of software that goes out and causes damage to a remote server. The user who used the software is still responsible. Of course the user may then go out and try to get recompense for the person who sold them the buggy software or the evil web form but the responsibility is still clear. Mark Nottingham has talked about this numerous times (including the real world limitations due to bad designs), one example is http://www.mnot.net/blog/2006/04/20/form.submit.

Tim - I would respectfully disagree. I believe that for APP's behavior to be RFC 2616 compliant it should have mandated that clients mark data they are "passing along" so as to distinguish it from data that the client is actually asking be changed on the server. Without this explicit distinction I believe it is impossible to enforce the safe/unsafe distinction defined in RFC 2616.

        Of course that's just my two cents,

                Yaron

> -----Original Message-----
> From: Tim.Bray@xxxxxxx [mailto:Tim.Bray@xxxxxxx]
> Sent: Wednesday, June 20, 2007 8:45 PM
> To: Yaron Goland
> Cc: atom-protocol@xxxxxxx
> Subject: Re: Question about section 9.3 of APP
>
> On Jun 20, 2007, at 5:23 PM, Yaron Goland wrote:
>
> > How does the working group resolve the apparently conflict between
> > section 9.3 of APP and section 9.1.1 of RFC 2616?
>
> I think you're straining at gnats here.  The language of the spec
> makes it entirely clear that the client is to reproduce content that
> it does not intend to change, no matter where it came from.  Should a
> dispute arise in practice about the result of some PUT transaction,
> it will be obvious whether the problem was due to client-sourced or
> server-sourced content.  2616 stands: PUT can change the state of the
> system.  That fact does not imply that the client is solely
> responsible, in the APP context, for all such changes in state.  -Tim
>
>