Subject: Partially fulfilled / draft-nottingham-http-new-status

From: "Markus Lanthaler" <[email-masked]>
Date: Tue, 6 Dec 2011 10:46:41 +0800

Hi,

First of all sorry for the cross-post, but I wasn't sure where to send it.

I've just stumbled across the "draft-nottingham-http-new-status" ID and was
wondering whether you considered to include a status code for partially
fulfilled requests. It is not unusual that a request can be considered as
successful even if it couldn't be fulfilled completely.

A purchase order, for example, could still be created even though not all
order items are available for order. The client can then revoke his order or
proceed with the checkout without having to place another order and risking
that other items get unavailable (think of ticketing where you often have
the possibility to reserve tickets for some minutes).

This would reduce the number of required round-trips and potential "lost
update" problems.

--

Markus Lanthaler

@markuslanthaler

---

From: "Markus Lanthaler" <[email-masked]>
Date: Tue, 6 Dec 2011 13:46:19 +0800

Mark,

I've considered 202 Accepted but it has a completely different meaning. 202
is defined as:

  "The request has been accepted for processing, but the processing has not
   been completed. The request might or might not eventually be acted
upon.."

I proposed to introduce a new status code for requests that have been fully
processed but could just be fulfilled partially. Thinking more about it I
came up with another example where this might be very useful.

Assume we have a Web service. Clients send requests and everything works
fine -> 200 OK. At a certain point in time the Web service adds new
optional(!) functionality which is not critical and clients start to use it.
A simple example could be that clients transmit some additional data. If the
server gets updated as well and understand all the data, again a 200 OK is
fine.

But if a server is not updated to the latest version it might understand
just parts of the request (the critical part) and simply ignore the other
parts. To tell the client that it successfully processed the request but
didn't understand parts of the request he would return a, e.g., 209
Partially Fulfilled.

I think such a behaviour would be very important in evolving systems. As far
as I know, there are currently only two ways to deal with it: either process
the request and return a 200 OK signalling everything was OK or ignoring the
request and returning a 400 Bad Request.

--
Markus Lanthaler
@markuslanthaler

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 06 Dec 2011 09:44:03 -0700

On 12/05/2011 10:46 PM, Markus Lanthaler wrote:

> It is not unusual that a request can be considered as successful even
> if it couldn't be fulfilled completely.

...

> request and returning a 400 Bad Request.

A third way would be to return a 200 OK response with an extension
response header or custom body that indicates which parts of the request
were not "fully fulfilled".

A forth way would be to include extension request headers or custom body
pieces indicating client preferences with regard to considering
partially fulfilled requests successful.

>From HTTP point of view, 200 OK seems like an appropriate response here
because the transaction went through and the HTTP server considered it a
success. The application-level details of that success can be left to
the extension headers or body.

A user-agent receiving just a "partially fulfilled" status code is
likely to want a lot more information anyway, resulting in the
additional requests you wanted to avoid. For example, a purchase
order-placing agent would want to know which items were not ordered
before deciding whether to revoke the partial order.

HTH,

Alex.

---

From: Sam Johnston <[email-masked]>
Date: Tue, 6 Dec 2011 19:08:25 +0000

> before deciding whether to revoke the partial order.

Agreed — if you're going to have to define a custom format anyway (as you
are in almost every case) then you're probably better off just using
existing codes.

"202 Accepted" applies to any state up to (but not including) completion,
so it's not really appropriate for synchronous requests, while "200 OK"
specifically allows for "an entity describing or containing the result of
the action".

That said, as I'm busy applying HTTP (as it was intended rather than with
envelope layers) to cloud standards I find myself regularly wanting to give
status updates — as x of y units, %, etc. — and it could be useful to have
a header that carried this information in a sensible/standard format. A
marked up Link: to a [text/uri-]list of components could be interesting too.

Sam

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 6 Dec 2011 16:44:22 -0800

On Dec 5, 2011, at 6:46 PM, Markus Lanthaler wrote:

> Hi,
>  
> First of all sorry for the cross-post, but I wasn’t sure where to send it.
>  
> I've just stumbled across the "draft-nottingham-http-new-status" ID and was wondering whether you considered to include a status code for partially fulfilled requests. It is not unusual that a request can be considered as successful even if it couldn't be fulfilled completely.
>  
> A purchase order, for example, could still be created even though not all order items are available for order. The client can then revoke his order or proceed with the checkout without having to place another order and risking that other items get unavailable (think of ticketing where you often have the possibility to reserve tickets for some minutes).
>  
> This would reduce the number of required round-trips and potential "lost update" problems.

When extending HTTP status codes, the question that needs to be asked
is "how will a client process this response differently than any of
the existing status codes?"

In particular, a "partially fulfilled request" can only occur with
POST and some of the depth-altering WebDAV methods.

For POST, this response is no different than 200 -- the client has no
idea what semantics are provided by the service and thus cannot
differentiate partial from complete success without the service
telling the client what to do next (i.e., exactly what 200 does).

For WebDAV, they defined 207 (and utter pain follows thereafter).

IMO, HTTP should avoid introducing partial failure conditions as
if that were a reasonable response.  Non-atomic services can be
redesigned as atomic services far easier than deploying clients
that can recover from arbitrary partial failures.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Dec 2011 13:03:33 +1100

Why is it necessary to surface this information in the status code? E.g., will intermediaries or automated software that's not specific to the application at hand be able to use it? 

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: "Markus Lanthaler" <[email-masked]>
Date: Wed, 7 Dec 2011 10:29:39 +0800

> partially fulfilled requests successful.

What do you mean by extension response/request headers? Are you talking
about RFC 2774 [1] or just some proprietary (X-)headers?

[1] http://www.ietf.org/rfc/rfc2774.txt

--
Markus Lanthaler
@markuslanthaler

---

From: "Markus Lanthaler" <[email-masked]>
Date: Wed, 7 Dec 2011 10:30:26 +0800

> telling the client what to do next (i.e., exactly what 200 does).

That's true. 

Mark Nottingham wrote:
> Why is it necessary to surface this information in the status code?

I just wanted to solely rely on the 200 code when the request was
*completely* fulfilled and have a way to signal the client to also look at
the body when it was *partially fulfilled*. But having a content length of 0
in the first case would basically do the same, right?

> E.g., will intermediaries or automated software that's not specific to
> the application at hand be able to use it?

Hmm... No. You are right, indeed it has no advantage of creating a specific
response code for that as it won't tell you more about the result than a
200.

Thank you very much for the feedback

Regards

--
Markus Lanthaler
@markuslanthaler

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 06 Dec 2011 22:08:13 -0700

> [1] http://www.ietf.org/rfc/rfc2774.txt

Any message extension headers as defined by RFC 2616 Section 7.1.
Whether they are [going to be] documented by some RFC, have an X-
prefix, and/or remain application-specific is not important for this
discussion, IMHO.

My point is that there are existing HTTP mechanisms that can be used to
report to the client that parts of a successful HTTP transaction were
not entirely successful from the application point of view (and that
those rich mechanisms appear to be more suitable than a single new
status code).

Compared to using extension headers and/or custom response bodies,
adding a new standard response code is a more rigid/limited solution and
its support is going to be more expensive for HTTP agents that do not
need to know about any of this (e.g. proxies already know how to ignore
extension headers or body content, but new status codes often require
explicit care).

On the other hand, since I am not writing applications that deal with
partially fulfilled requests, I could be easily missing something that
prompts folks to suggest a new response status code instead.

Cheers,

Alex.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Dec 2011 09:00:49 -0700

> prefix, and/or remain application-specific is not important for this

I agree that it's not important in this context.

FYI, please note that we're trying to get rid of the x- prefix...

http://tools.ietf.org/html/draft-ietf-appsawg-xdash

Speaking of which, I need to ping the APPSAWG chairs about starting a
last call. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Dec 2011 10:43:23 +1100

On 07/12/2011, at 6:08 AM, Sam Johnston wrote:

> That said, as I'm busy applying HTTP (as it was intended rather than with envelope layers) to cloud standards I find myself regularly wanting to give status updates — as x of y units, %, etc. — and it could be useful to have a header that carried this information in a sensible/standard format. A marked up Link: to a [text/uri-]list of components could be interesting too.

Julian has been known to use a data: URI in a Link header… 

--
Mark Nottingham
http://www.mnot.net/