Rejecting non-idempotent requests safely

[martinthomson]

The REFUSED_STREAM error code on RST_STREAM has an unexplained, yet potentially important property. This error code is a clear signal to the receiver that the framing layer did not pass any frames to an upper layer for processing.

This allows a client to use this error code as a signal that the HTTP request it made can be safely retried, even if that request would not ordinarily permit that. That is, a client (or intermediary ?) can safely retry an non-idempotent request.

This gets around the retry prohibition in http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22#section-6.3.1

This needs to be better explained, perhaps with a new section in the HTTP usage section.

See thread starting at http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/1353.html

[jasnell]

I'm not sure that it's safe to always assume that automatic retry is safe for the REFUSED_STREAM case. There could be many reasons why the stream was refused and automatic retry could lead to abuse or could make the situation worse. Perhaps a separate status code (e.g. REFUSED_STREAM_RETRY_OK) would be better for this? That gives the server a slight bit more control over how things are handled.

[jpinner]

The assertion here is that automatically retrying a request is safe from an HTTP semantic point of view. It does not give any assertion that a stream will be accepted if it is retried. I'm not sure how useful a separate status code would be as it does not really provide the server any control. The server would always have to be prepared to handle abusive clients.

[martinthomson]

James,

This is what I believe was the intent:

The distinction between REFUSED_STREAM and CANCEL is that REFUSED_STREAM
permits retry, CANCEL might not. If you are certain that a stream can be
retried, send REFUSED_STREAM, otherwise send CANCEL.

That isn't effectively captured in the spec. As long as this is OK from a
design perspective, capturing that should be easy.

On 23 April 2013 14:11, Jeff Pinner notifications@github.com wrote:

The assertion here is that automatically retrying a request is safe from
an HTTP semantic point of view. It does not give any assertion that a
stream will be accepted if it is retried. I'm not sure how useful a
separate status code would be as it does not really provide the server any
control. The server would always have to be prepared to handle abusive
clients.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/57#issuecomment-16886727
.

[jasnell]

I can live with that kind of differentiation between CANCEL and REFUSED_STREAM.

[willchan]

Is the design label correct for this? AIUI, there's no contention here, it just needs to be explained better than we did in SPDY. I believe this just needs editorial work.

[willchan]

Oops, I gagged at re-reading my comment. I hate adding to procedural nonsense :P

[mnot]

Discussed at SF Interim; Martin to incorporate and James to review.

[mnot]

In; @jasnell please review.

[jasnell]

The current wording in the spec is sufficient on this I think... with the exception of the last paragraph regarding PING... the ability to send a PING doesn't really have anything to do with automatic request retry... I'd scrub that last paragraph.