Error behavior?

[Carl Howells]

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 
paramaters:
   * openid.mode=error
   * 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?

Carl