chowells at janrain.com
Wed Jun 15 15:53:04 PDT 2005
Carl Howells wrote:
> Martin Atkins wrote:
>> However, since they are messages to a person for debugging they don't
>> need to be machine-readable. The machine just needs to see "protocol
>> error" and some natural language string. Natural language does present
>> the difficulty that the programmer might not understand the language
>> that the ID server speaks, but I doubt we can achieve anywhere near the
>> right amount of granularity through error response codes without
>> building up an entire library of them which need to be handled... and
>> they still need to be described in natural language somewhere anyway.
> Ok. I agree with everything you posted. I suppose that means I'm
> asking for something in the spec that describes precisely what the
> mechanism *is* to return a protocol error message.
And since no one is stepping in to make a proposal, I'll start. Then
you can tell me how broken it is and how to fix it. :)
On a protocol error in the server, (but *not* an authentication failure
that followed the protocol correctly), there are two possible behaviors:
1. As a response to a GET, if the openid.return_to field was properly
specified, redirect to the return_to url setting these additional url
* openid.error=Some human readable string
2. In any other case (POST, or return_to not specified) return a 200
(that's probably not the best choice) server response with content type
text/plain, where the body is the same two key:value pairs as described
above, in the standard key:value form used in POST responses.
What does everyone think of this? How can it be improved? Should the
server response really be a 200 if it can't use a redirect instead?
More information about the yadis