Right now text has hardcoded Retry-After: 1 for every 429 request.
Requestctl could provide a more accurate value iff threshold_duration is provided
Right now text has hardcoded Retry-After: 1 for every 429 request.
Requestctl could provide a more accurate value iff threshold_duration is provided
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Restricted Task | |||||
| Open | None | T305580 requestctl v1 improvements | |||
| Resolved | Joe | T305824 Provide a meaningful Retry-After value |
The data could be passed via an HTTP header on the req object on cluster_fe_ratelimit and picked up on wikimedia-frontend vcl_synth to set the response header. Considering that the request won't leave varnish it doesn't look like an awful solution to pass the data from request to response context.
Change 791006 had a related patch set uploaded (by Giuseppe Lavagetto; author: Giuseppe Lavagetto):
[operations/software/conftool@master] requestctl: add retry-after request header when applicable
Change 791006 merged by jenkins-bot:
[operations/software/conftool@master] requestctl: add retry-after request header when applicable
Change 791373 had a related patch set uploaded (by Giuseppe Lavagetto; author: Giuseppe Lavagetto):
[operations/puppet@production] varnish: set retry-after based on throttle duration in requestctl
Change 791373 merged by Giuseppe Lavagetto:
[operations/puppet@production] varnish: set retry-after based on throttle duration in requestctl