Re: PaceServiceError comments

[Robert Sayre <mint@xxxxxxxxxxxxxxx>]

On 6/22/04 6:26 PM, "Bill de hÓra" <bill@xxxxxxxxxx> wrote:

> 
> Robert Sayre wrote:
> 
> 
>> Give an example of a POST request/response to compare.
> 
> Just change GET to POST:
> 
> 
> [Client A to Server ErrorURI]
> 
> C:  POST http://eg.org/errors/foo/bar/17/09/30 HTTP/1.1
> C:  User-Agent: Client-A/1.0
> 
> S:  HTTP/1.1 204 No Content
> 
...
> 
> 
> Some more comments:
> 
> - for the server ack on the ErrorURI, 202 seems at least as
> applicable as 204.
>

"the server ack"

Yep. Returning 204 from a POST implies that the server actually logged the
data. PaceServiceError doesn't currently confirm or reject any change or
update--it acknowledges it (the Pace says exactly this). So 204 in response
to a POST is inappropriate for the ErrorURI. There should be no indication
to a malicious or buggy client that it should keep trying.

The second paragraph[1] of "202 Accepted" is a poor fit for
PaceServiceError. Note that there is nothing meaningful to return in the
message body. This violates a SHOULD-level recommendation. It seems like 202
is for "process that terabyte of experimental data" or something like that.

So, what would the correct status code be?

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

"Naturally, it is not possible to ensure that the server does not  generate
side-effects as a result of performing a GET request; in  fact, some dynamic
resources consider that a feature. The important  distinction here is that
the user did not request the side-effects,  so therefore cannot be held
accountable for them."

If this is not a valid use case for this section of the spec, what would be?
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?

> - There's some work to be done on the server to ensure generation
> of new ErrorURIs on feed updates (410 Gone implies URI disposal).
> Not a big deal, but worth pointing out.

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.

Robert Sayre

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1