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

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 14 Aug 2011 08:03:44 +0300

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.

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.

Mykyta Yevstifeyev

> FYI; a few new status codes.
>
> I suspect this might end up in the APPAWG, since it's out of scope for HTTPBIS.
>
> Cheers,
>
>
>
> Begin forwarded message:
>
> >  From:[email-masked]  <mailto:[email-masked]?Subject=Re%3A%20Fwd%3A%20I-D%20Action%3A%20draft-nottingham-http-new-status-00.txt&In-Reply-To=%253C499F702D-445A-4845-BD72-ACED733A6B67%40mnot.net%253E&References=%253C499F702D-445A-4845-BD72-ACED733A6B67%40mnot.net%253E>
> >  Subject: I-D Action: draft-nottingham-http-new-status-00.txt
> >  Date: 13 August 2011 5:26:19 PM AEST
> >  To:[email-masked]  <mailto:[email-masked]?Subject=Re%3A%20Fwd%3A%20I-D%20Action%3A%20draft-nottingham-http-new-status-00.txt&In-Reply-To=%253C499F702D-445A-4845-BD72-ACED733A6B67%40mnot.net%253E&References=%253C499F702D-445A-4845-BD72-ACED733A6B67%40mnot.net%253E>
> >  Reply-To:[email-masked]  <mailto:[email-masked]?Subject=Re%3A%20Fwd%3A%20I-D%20Action%3A%20draft-nottingham-http-new-status-00.txt&In-Reply-To=%253C499F702D-445A-4845-BD72-ACED733A6B67%40mnot.net%253E&References=%253C499F702D-445A-4845-BD72-ACED733A6B67%40mnot.net%253E>
> >
> >  A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> >  	Title           : Additional HTTP Status Codes
> >  	Author(s)       : Mark Nottingham
> >                           Roy T. Fielding
> >  	Filename        : draft-nottingham-http-new-status-00.txt
> >  	Pages           : 8
> >  	Date            : 2011-08-13
> >
> >    This document specifies additional HyperText Transfer Protocol (HTTP)
> >    status codes for a variety of common situations.
> >
> >
> >  A URL for this Internet-Draft is:
> >  http://www.ietf.org/internet-drafts/draft-nottingham-http-new-status-00.txt
> >
> >  Internet-Drafts are also available by anonymous FTP at:
> >  ftp://ftp.ietf.org/internet-drafts/
> >
> >  This Internet-Draft can be retrieved at:
> >  ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-new-status-00.txt
> >  _______________________________________________
> >  I-D-Announce mailing list
> >  [email-masked]  <mailto:[email-masked]?Subject=Re%3A%20Fwd%3A%20I-D%20Action%3A%20draft-nottingham-http-new-status-00.txt&In-Reply-To=%253C499F702D-445A-4845-BD72-ACED733A6B67%40mnot.net%253E&References=%253C499F702D-445A-4845-BD72-ACED733A6B67%40mnot.net%253E>
> >  https://www.ietf.org/mailman/listinfo/i-d-announce
> >  Internet-Draft directories:http://www.ietf.org/shadow.html
> >  orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> --
> Mark Nottinghamhttp://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 16 Aug 2011 09:47:17 +1000

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.

>> > From: 
>> [email-masked]
>> > To: 
>> [email-masked]
>> > Reply-To: 
>> [email-masked]
>> [email-masked]
>> > or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
>> 
>> --
>> Mark Nottingham   
>> http://www.mnot.net/
> 

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

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 16 Aug 2011 07:08:37 +0300

> What's the advantage over just closing the connection?

Well, Wikipedia claims that such code may be useful as a "deterrent for 
malware" (http://en.wikipedia.org/wiki/List_of_HTTP_status_codes), 
giving no other information.  I don't actually know how exactly it works 
for this reason, but I suspect that when the origin server has detected 
that it is infected by some malware, and its policy is to immediately 
disconnect from the Net, and, respectively, all UAs connected, it will 
choose to close the connection by 444 response, giving no other 
information.  In other words, 444 is useful in the case of "emergency", 
when something happens to server.

Also, 444 is very similar to FTP 421 code, that is defined as follows:

>           421 Service not available, closing control connection.
>               This may be a reply to any command if the service knows it
>               must shut down.

Similar code exists in SMTP 
(http://tools.ietf.org/html/rfc5321#section-4.2.2):

>     421<domain>  Service not available, closing transmission channel
>        (This may be a reply to any command if the service knows it must
>        shut down)

[Hmm, the code number, and the description are suspiciously 
similar...:-) ]  So I believe such code may also be useful in HTTP.

> Hmm. I could see this as a server-side version of 'limit exceeded' I suppose... interesting.

Yes, these two are quite contiguous.

So I'm looking forward to new version of your draft.

Mykyta Yevstifeyev

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 16 Aug 2011 07:58:00 +0200

Hi Mukyta,

> when something happens to server.

Well, then it should be a 5xx, not a 4xx, as the problem is not related to
the client's request but to the server's operational condition. Probably
that this 444 was randomly picked as handful at that time without much
preliminary thinking. I observe that 4xx and 5xx are often mixed in field
and that's pretty concerning, because it makes troubleshooting much more
complicated.

Regards,
Willy

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 16 Aug 2011 11:15:48 +0300

> and that's pretty concerning, because it makes troubleshooting much more

Yes, in the way I describe it 5xx is indeed more appropriate; but I may 
be wrong when describing semantics of the code.  It may be that 444 
might also be caused by the client's request, as it's assumed by 4xx 
designation, but...  I think this question will be cleared up should we 
determine how nginx uses 444.

ADDITION: This is what I've found on the Net regarding 444 
(https://calomel.org/nginx.html):

> The security mindset of the configuration is very paranoid. There are 
> a significant amount of bots, scanners and broken clients that will 
> abuse your site if given the opportunity. These clients will waste 
> your bandwidth and system resources. As a response, we will not trust 
> any client to access our server without first making sure that all of 
> the request parameters are met. This means that the remote client must 
> be asking for our site by the proper host name and must request any 
> support files, like pictures and css, with the referrer headers 
> properly set. Any deviation from these rules will lead to Nginx 
> dropping the client's connection with a return code 444. Even though 
> Nginx does not have a module like mod_security we can still make our 
> own access rules. Note that even though these rules are strict, normal 
> web traffic and bots like Google can access the site without issue.

So what I described above isn't right, after all :-).  444 actually 
means that the server isn't willing even to begin processing client's 
request.  For the situation I described above 500 response should be fine.

Mykyta Yevstifeyev