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

Re: Feedback on draft-sigurdsson-anti-ddos-http-throttling

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 12 Oct 2011 15:23:02 +1100
Cc: Adam Barth <w3c@adambarth.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1F892E00-7B3C-4B4B-BEF3-A683FE7C870B@mnot.net>
To: Jói Sigurđsson <joi@google.com>

On 11/10/2011, at 5:31 AM, Jói Sigurđsson wrote:

> Hi Mark,
> 
> Thanks a lot for the feedback.
> 
> I was ambivalent about reusing the Retry-After header.  As far as I
> can tell, the semantics are unchanged when encountered on a response
> with a 503 status code, which AFAICT is the only status code it is
> observed for per current HTTP standards.  The addition in this
> Internet-Draft is to observe the header for responses with other
> status codes.  My thought was that since implementations should ignore
> unknown headers, this wouldn't dilute interop, but I wasn't sure.  It
> sounds like the simplest route is to use a new header, but would love
> your thoughts on the reasoning above before I go there.

I'm mostly concerned because people have talked about using Retry-After for other purposes on other status codes; e.g., on a 202 Accepted, it might indicate how long to wait before polling a status resource, and so on. 

These other uses may or may not conflict with your re-purposing of Retry-After, and strictly speaking, it's already allowed on other responses, in that it isn't prohibited from occurring there; it's just that the semantics are not well-defined.*

One question -- I didn't see anywhere where Retry-After was used in your algorithm; it's referenced as a way for Ajax applications to control polling frequencies. However, this could be done by agreement between the client and server (e.g., using something in the response body, and/or another response header), correct?

Cheers,


* As a side note, I wonder if we can generalise retry-after semantics to apply to all responses where there's a Location header, as well as server-side errors...


> I should note that the existing implementation does not actually
> interpret Retry-After this way, it uses an X-header since there is no
> standard yet.
> 
> I will look into registering the headers as you mentioned.  Thanks for
> the reference.
> 
> Cheers,
> Jói
> 
> 
> On Mon, Oct 10, 2011 at 3:41 AM, Mark Nottingham <mnot@mnot.net> wrote:
>> Hi Joi,
>> 
>> I just noticed your draft <http://www.ietf.org/id/draft-sigurdsson-anti-ddos-http-throttling-00.txt> and had a quick look through it.
>> 
>> One thing that stood out was your re-definition of the Retry-After HTTP header; modifying the semantics of an existing header is generally not a good idea (as doing so dilutes interop). If it does need changing, that needs to be done in consultation with the entire community, not unilaterally.
>> 
>> I'd suggest you define a different header; if you really need to use Retry-After, please engage with the HTTPbis WG (CC:ed).
>> 
>> Also, you'll need to register whatever headers you define; see RFC3864.
>> 
>> Regards,
>> 
>> 
>> --
>> Mark Nottingham   http://www.mnot.net/
>> 
>> 
>> 
>> 

--
Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 12 October 2011 04:23:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:48 GMT