[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PaceServiceError comments


Robert Sayre wrote:

to a malicious or buggy client that it should keep trying.

The second paragraph[1] of "202 Accepted" is a poor fit for
PaceServiceError.

It's a good fit for a POST to ErrorURI, not for a GET against an ErrorURI, but we don't agree yet on the intended side effects or not. 204 is a good code for GET.


Note that there is nothing meaningful to return in the
message body.

There doesn't have to be, but point taken.


This violates a SHOULD-level recommendation.

Violation of a SHOULD is not always a problem ime - that's why it's a SHOULD.


It seems like 202
is for "process that terabyte of experimental data" or something like that.

Point taken, but 202 is not just for that.


I want to return to section 9.1.1 of the HTTP spec[2]:

[...]
If this is not a valid use case for this section of the spec, what would be?

That depends on whether people think GET or POST makes most sense - discusion ongoing elsewhere.


Is this paragraph utter nonsense? This would seem to indicate that GETs need
not be side-effect free, only that the user has committed to nothing by
sending the request. By sending a request to the ErrorURI, what has the user
committed to that exceeds a normal GET request?

Sure, but work with me here. You asked for a POST example - I gave it - now you're back to GET.


There's no requirement that the server ever change the URI, though doing so
would certainly be useful. Keeping previous URIs dead is implied by the 410
status code.

I'm not sure anything other than a disposable URI is manageable. If you extend the call sequence over a few errors/fixes that might become apparent (the server flipping back to the feed to figure out whether to send a 410 or not). an implementation detail perhaps, tho' I think 410 is meant to be a permanent thing not a bit flip.

GET or POST aside - I still like this pace.

cheers