W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: I-D Action: draft-nottingham-http-new-status-00.txt

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 02 Dec 2011 23:13:09 +0100
Message-ID: <4ED94D75.5030105@gmx.de>
To: Peter Saint-Andre <stpeter@stpeter.im>
CC: Mark Nottingham <mnot@mnot.net>, Mykyta Yevstifeyev <evnikita2@gmail.com>, ietf-http-wg@w3.org
On 2011-12-02 22:35, Peter Saint-Andre wrote:
> On 8/15/11 5:47 PM, Mark Nottingham wrote:
>> On 14/08/2011, at 3:03 PM, Mykyta Yevstifeyev wrote:
>>> Hello Mark,
>>> I also think APPSAWG can be appropriate for discussion and processing this document.
>>> I recall the existence of non-standard 444 status code, which stands for 'No Response' and is currently used by nginx servers.  Should we standardize it?  I'll describe briefly.  I suppose the semantics are "due to some reasons the server has chosen to close the connection and return no response to the user"; thus the body in 444 response must be empty.  444 responses must not be stored by the caches, and receiving one should not prevent the user from retrying opening the connection once more.  444 responses should not be generated by intermediaries; they can only be given by the origin servers.
>> What's the advantage over just closing the connection?
>>> Another widely-used (and probably even more often than 444) is 509, 'Bandwidth Limit Exceeded'.  This is returned when a server or an intermediary encounters the situation when due to the limitation of the bandwidth it is unable to process client's request or server's response, respectively.  No caching is allowed as well; "Retry-After" may be present.  I think we can standardize this status code as well.
>> Hmm. I could see this as a server-side version of 'limit exceeded' I suppose... interesting.
> Interesting enough to include in draft-nottingham-http-new-status?
> (Yes, I am reviewing that I-D so that I can create the proto writeup.)
> ...

Well, at some point we need to stop :-). I'd also like to propose a 
fixed version of 302 (as 307 "fixes" 301), but I'll have to do more 

We can repeat this exercise every few years; let's get those that have 
we have now defined and registered!

Best regards, Julian
Received on Friday, 2 December 2011 22:13:45 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:26 UTC