W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

RE: [Fwd: I-D ACTION:draft-dusseault-http-patch-09.txt]

From: Yaron Goland <yarong@microsoft.com>
Date: Fri, 7 Sep 2007 10:26:27 -0700
To: James M Snell <jasnell@gmail.com>
CC: Julian Reschke <julian.reschke@gmx.de>, Henrik Nordstrom <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <AE9A8CBCE1A9744D975A9FBBF822DD785FC65E99E2@NA-EXMSG-C102.redmond.corp.microsoft.com>

Warning codes, in the wild, have, in my experience, failed. Most HTTP clients don't have a way to view them and almost no HTTP client programmers appear to know they exist so I wouldn't want to use a warning code.

My current plan is to just return a header but the semantics of the header are "This is a GET response". What I think you want is a different kind of header that means "there may have been changes to the state of the resource between the time your method was applied and this in-line get response was returned."

BTW, I must admit that I still haven't seen any compelling use case for 209 as it is currently defined (e.g. with race condition protection). Just because something can be done doesn't mean it should be done. Before we put it in a standard we should make sure there is a compelling need for it.

        Just my two cents,

                        Yaron

> -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: Friday, September 07, 2007 10:23 AM
> To: Yaron Goland
> Cc: Julian Reschke; Henrik Nordstrom; HTTP Working Group
> Subject: Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-09.txt]
>
>
> Yaron Goland wrote:
> > [snip]
> > #1 - I don't believe that 209 with race condition protection is
> actually necessary. Although I could easily be convinced that I'm wrong
> if someone has a killer use case.
> >
>
> It's not necessary in every case, which is why the spec does not make
> it
> a MUST.  It should be possible to provide race condition protection
> without requiring it.
>
> > #2 - We absolutely need the ability to return a 209 without race
> condition guarantees. So if 209 is going to be defined with a race
> condition prevention requirement then we can't use 209 and will need to
> do something else.
> >
>
> Well, I'm wondering if there is some way we can signal in the 209
> response whether or not some other change has occurred.  I know warning
> codes are not the Cool Thing, but something along those lines would be
> helpful to indicate that the resource has been modified before the 209
> response was returned.
>
> Do you have a suggestion for what that signal could be? response
> header?
> warning code? something else?
>
> - James
>
Received on Friday, 7 September 2007 17:26:41 GMT

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