> On Oct 30, 2009, at 11:01 AM, Lisa Dusseault wrote:
> > This is clearly a tradeoff between server flexibility and client's
> > being able to know what to do, so let's look at whether a client can
> > actually do something with the information. In the case of a
> > concurrent patch, if the clie
On 10/30/09 10:27 PM, Nikunj R. Mehta wrote:
On Oct 30, 2009, at 11:01 AM, Lisa Dusseault wrote:
Hi,
On Wed, Oct 28, 2009 at 11:03 AM, Nikunj R. Mehta
wrote:
This draft places unreasonable restriction on servers about processing
requests. Specifically, in §2.2,
[[
Concurrent modificati
Hi Lisa,
At 10:07 30-10-2009, Lisa Dusseault wrote:
> Malformed patch document: When the server determines that the patch
> document provided by the client is not properly formatted, it SHOULD
> return a 400 (Bad Request) response. The definition of badly
> formatted depends on
On Oct 30, 2009, at 11:01 AM, Lisa Dusseault wrote:
Hi,
On Wed, Oct 28, 2009 at 11:03 AM, Nikunj R. Mehta
wrote:
This draft places unreasonable restriction on servers about
processing
requests. Specifically, in §2.2,
[[
Concurrent modification: When a server receives multiple concurren
Hi,
On Thu, Oct 29, 2009 at 11:29 AM, SM wrote:
>
> In Section 2:
>
> "If the entire patch document cannot be successfully applied
> then the server MUST fail the entire request, applying none
> of the changes."
>
> I suggest rewriting the sentence:
>
> If the entire patch document cannot
Hi,
On Wed, Oct 28, 2009 at 11:03 AM, Nikunj R. Mehta
wrote:
>
> This draft places unreasonable restriction on servers about processing
> requests. Specifically, in §2.2,
>
> [[
> Concurrent modification: When a server receives multiple concurrent requests
> to modify a resource, those requests S
At 07:40 27-10-2009, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'PATCH Method for HTTP '
as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Pleas
This draft places unreasonable restriction on servers about processing
requests. Specifically, in §2.2,
[[
Concurrent modification: When a server receives multiple concurrent
requests to modify a resource, those requests SHOULD be queued and
processed in the order in which they are received
Nikunj R. Mehta wrote:
This draft places unreasonable restriction on servers about processing
requests. Specifically, in §2.2,
[[
Concurrent modification: When a server receives multiple concurrent
requests to modify a resource, those requests SHOULD be queued and
processed in the order in
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'PATCH Method for HTTP '
as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive c
The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'PATCH Method for HTTP '
> as a Proposed Standard
This could be sort of a nitpick, but
It seems to me that this could be used for both simple sequences of
bytes, and
11 matches
Mail list logo
