- From: Jói Sigurđsson <joi@google.com>
- Date: Wed, 12 Oct 2011 17:33:57 +0000
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Adam Barth <w3c@adambarth.com>, HTTP Working Group <ietf-http-wg@w3.org>
Thanks Mark. It sounds like it's safest to use a separate header instead of Retry-After, e.g. Block-Retry-Until or some such (will think about the naming a bit in the larger context of the I-D). > 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? When encountering a Retry-After header (or whatever header name we end up with), the algorithm would set the release_time variable for the throttling target in question to the indicated time, so all requests to the throttling target until that time would be blocked. The Ajax thing was an illustrative example, but indeed I think this header might be most useful when providing a "web service" kind of thing, where it's common for clients to poll on a regular basis. You're right that there could be an agreement between client and server that is implemented in the application layer of the client, but this relies on all clients observing the agreement, and it adds an implementation overhead to each client of each such service. I believe a mechanism in the protocol layer would be more useful, if it becomes a widely-adopted standard. Cheers, Jói 2011/10/11 Mark Nottingham <mnot@mnot.net>: > > 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 Thursday, 13 October 2011 11:06:19 UTC