Re: [apps-discuss] draft-nottingham-http-problem

[Erik Wilde <[e-mail]>]

hello ray.

On 2013-03-14 08:26 , Ray Polk wrote:
> True; error location & multiple errors are useful for validation of the body.  Those notions might also be useful for multiple input errors of other types as well, right?
> 403 - we return 403 when user agents provide incorrect CSRF prevention tokens &/or access_tokens &/or don't have permission.  we're required to inform UA of the issue (otherwise return 404); if both the CSRF token & access_token are wrong, we'd like to inform on both issues in one response; possibly specifying the erroneous query param or entity value.

when it comes to authentication, exposing too much detail definitely 
always may be a security issue. (the same is btw true for exposing 
implementation details such as software details/version, or even more 
detailed reports such as crash reports.)

> 406 - UA might have gotten more than one header wrong; so might be good to specify which headers were wrong in order to scope the required list of valid values

406 specifically talk about providing details in a content type capable 
of doing so. while services are free to use their own, they might as 
well choose to use an HTTP problem report. i am not sure whether this 
(since it's part of HTTP itself) might warrant some special handling in 
the problem report schema. it could be either this, or there could just 
be growing consensus about a problemType and how 406 are handled.

> 409 - where multiple fields violated some kind of scope/uniqueness constraint

i think this is very similar to the 406 situation.

> Multiple errors needn't be only with input (headers, query parameters, request body) either.  I could envision a request causing more than one top level error (say...406 & 409 at the same time).

that's simply impossible because of how HTTP works currently. why i do 
get your point, you can only report a 406 or a 409, and then include the 
details for that. we don't want to change HTTP error handling.

> So anyway, w/e was chosen for error location (errorPath / errorFragmentIdentifier / ...) might need to handle identifying header, query param, request entity field....matrix param?  ...path param?!  ...or should there be one response field per input type?  ...or...?

yes, but that would be up for the problemType to specify.

> Could you provide an example of using an anchor / frag id?  would it just be the json/yaml/xml/... field prefixed with a hash?

given that the context of an HTTP response is the request URI, i assume 
that using just a relative URI (starting with a hash) might be one way 
to go. on the other hand, such a relative URI would be a fragment of the 
*resource*, and not of the *request entity*, so maybe it would be a bad 
idea to do it like this. i am actually not quite sure how to best 
address this (since the request entity is not really a resource with a 
referencable URI), but maybe mark has some idea here.

thanks and cheers,

dret.

-- 
erik wilde | mailto:[e-mail]  -  tel:[phone] |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |