- From: Peter Saint-Andre <stpeter@stpeter.im>
- Date: Fri, 02 Dec 2011 14:35:05 -0700
- To: Mark Nottingham <mnot@mnot.net>
- CC: Mykyta Yevstifeyev <evnikita2@gmail.com>, ietf-http-wg@w3.org
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.) Peter -- Peter Saint-Andre https://stpeter.im/
Received on Friday, 2 December 2011 21:35:35 UTC