I'm good with this change.
BTW, I suggest we put parenthesis around the new sentences, making it clear
that they are an aside, rather than a normative part of the error code
definitions. So the text would then read:
server_error
The authorization server encountered an unexpected
condition which prevented it from fulfilling the request.
(This error code is needed because a 500 Internal Server
Error HTTP status code cannot be returned to the client
via a HTTP redirect.)
temporarily_unavailable
The authorization server is currently unable to handle
the request due to a temporary overloading or maintenance
of the server. (This error code is needed because a 503 Service
Unavailable HTTP status code cannot be returned to the client
via a HTTP redirect.)
-- Mike
From: [email protected] [mailto:[email protected]] On Behalf Of John
Bradley
Sent: Saturday, July 14, 2012 5:40 PM
To: Dick Hardt
Cc: [email protected]; Honton, Charles; [email protected] WG
Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2
I am OK with that wording. It is not a change just a clarification that may
make things clearer to developers.
John B.
On 2012-07-14, at 6:18 PM, Dick Hardt wrote:
Great suggestion Charles. I think this is a good clarification. I'll adjust the
copy you sent to be what follows in a new draft published tomorrow evening
(Sunday PT) unless someone objects.
-- Dick
In both sections 4.1.2.1 and 4.2.2.1:
server_error
The authorization server encountered an unexpected
condition which prevented it from fulfilling the request.
This error code is needed because a 500 Internal Server
Error HTTP status code cannot be returned to the client
via a HTTP redirect.
temporarily_unavailable
The authorization server is currently unable to handle
the request due to a temporary overloading or maintenance
of the server. This error code is needed because a 503 Service
Unavailable HTTP status code cannot be returned to the client
via a HTTP redirect.
On Jul 13, 2012, at 9:45 AM, Honton, Charles wrote:
Just to make sure I understand...
If the Authorization Server returns a 5xx, the User-Agent will immediately
display a error message.
If the Authorization Server returns an error code in the redirect, the Client
can take alternative actions or appropriately message the error.
If this is correct, perhaps a slight change in wording will explain the lack of
symmetry in the error codes.
In both sections 4.1.2.1 and 4.2.2.1:
server_error
The authorization server encountered an unexpected
condition which prevented it from fulfilling the request.
Using this error code allows the Client to handle this
condition instead of the User-Agent
temporarily_unavailable
The authorization server is currently unable to handle
the request due to a temporary overloading or maintenance
of the server. Using this error code allows the Client
to handle this condition instead of the User-Agent
Thanks,
chas
From: John Bradley <[email protected]<mailto:[email protected]>>
Date: Friday, July 13, 2012 9:08 AM
To: Charles Honton <[email protected]<mailto:[email protected]>>
Cc: Dick Hardt <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]> WG"
<[email protected]<mailto:[email protected]>>
Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2
4.2.2.1 and 4.1.2.1 are error codes that are returned to the client through the
browser via a 302 redirect.
You can't send a 5xx error via a 302 redirect.
That is why those need error messages specific to OAuth.
Errors not being sent via redirect use normal http error codes.
I thought that was clear. Is there some general confusion on this?
John B.
On 2012-07-13, at 11:55 AM, Honton, Charles wrote:
Great! Because this question has come up multiple times, perhaps the rfc could
explain the use of 5xx return code in addition to error_code.
I must be missing something. Why are server_error and temporarily_unavailable
specified in sections 4.2.2.1 and 4.1.2.1? Is there a distinction between 5xx
return code and error_code in these cases?
Chas
From: John Bradley <[email protected]<mailto:[email protected]>>
Date: Friday, July 13, 2012 4:04 AM
To: Dick Hardt <[email protected]<mailto:[email protected]>>
Cc: Charles Honton
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]> WG"
<[email protected]<mailto:[email protected]>>
Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2
FRom what I can see in a similar discussion Eran pointed out that this is a
direct communication, communication between the client and token endpoint.
Server Error and temporarily unavailable are not OAuth specific and are handled
by existing HTTP error codes.
I don't see a need for a change.
Unless something else dramatic comes up I would like to see draft 29 go to the
RFC editor.
(Though one person mentioned to me that 30 is a nicer number:)
John B.
On 2012-07-12, at 8:09 PM, Dick Hardt wrote:
Charles
Thanks for the suggestion. I just did publish a new draft that included a
number of items that had been discussed and I would like to get some feedback
on your suggestion before incorporating it (or not).
Does anyone have feedback on the change below? (+/-)
-- Dick
On Jul 12, 2012, at 1:45 PM, Honton, Charles wrote:
E. Hammer, D. Recordon, D. Hardt, et.al,
I'm looking at draft 28 (http://tools.ietf.org/html/draft-ietf-oauth-v2-28).
In Section 5.2 the error code should probably include:
server_error
The authorization server encountered an unexpected
condition which prevented it from fulfilling the request.
temporarily_unavailable
The authorization server is currently unable to handle
the request due to a temporary overloading or maintenance
of the server.
Regards,
chas
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
