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

On 12/06/2011 07:29 PM, Markus Lanthaler wrote:
> On Tue, Dec 6, 2011 at 4:44 PM, Alex Rousskov wrote:
> 
>> 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.
> 
> 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

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.

Received on Wednesday, 7 December 2011 05:09:39 UTC