HTTP 425 Too Early retry handling (RFC 8470) + Retry-After support for 429/503

[arturobernalg]

• Retries once on 425 Too Early.
• Optionally retries idempotent requests on 429/503, honoring Retry-After (delta-seconds or HTTP-date).
• Ensures retries only for idempotent methods and repeatable entities/producers.
• Signals TLS layer to disable early data on retry (http.client.tls.early_data.disable).

[ok2c]

@arturobernalg Do I understand it correctly this change-set implements a subset of RFC 8470, namely the retry part, and does not implement early data requests at all?

[arturobernalg]

@arturobernalg Do I understand it correctly this change-set implements a subset of RFC 8470, namely the retry part, and does not implement early data requests at all?

Yes, that’s correct: this change-set only implements the HTTP-side handling of 425 Too Early (single retry, and the retry is marked to avoid early data). It does not implement sending requests in TLS 1.3 0-RTT early data.

[ok2c]

@arturobernalg Do I understand it correctly this change-set implements a subset of RFC 8470, namely the retry part, and does not implement early data requests at all?

Yes, that’s correct: this change-set only implements the HTTP-side handling of 425 Too Early (single retry, and the retry is marked to avoid early data). It does not implement sending requests in TLS 1.3 0-RTT early data.

@arturobernalg This makes no sense. How would we get 425 status if we are not able to generate early data requests at all?

[arturobernalg]

@arturobernalg Do I understand it correctly this change-set implements a subset of RFC 8470, namely the retry part, and does not implement early data requests at all?

Yes, that’s correct: this change-set only implements the HTTP-side handling of 425 Too Early (single retry, and the retry is marked to avoid early data). It does not implement sending requests in TLS 1.3 0-RTT early data.

@arturobernalg This makes no sense. How would we get 425 status if we are not able to generate early data requests at all?