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

From: Ray Polk <[email-masked]>
Date: Thu, 14 Mar 2013 08:26:08 -0700 (PDT)

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.

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

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

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).

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...?

-----------

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

-----------

Regarding "more" -- custom top level field are also allowed in the response, right?  to be ignored by clients?  (per sec 3.3)  If that's the case, is there need for the "more" section?

Regards,
Ray

----- Original Message -----
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Sent: Friday, March 8, 2013 5:45:47 PM GMT -07:00 US/Canada Mountain
Subject: Re: [apps-discuss] draft-nottingham-http-problem

hello ray.

thanks for the feedback.

On 2013-03-08 14:28 , Ray Polk wrote:
> I think http-problem is a good idea, and we're looking at adopting it.
> A few questions:
> Has the notion of errorField or problemPath been considered?  Given a
> problem, say 422, it might be useful to point out the associative array
> entry / attribute / field that was problematic.  The value could be the
> field name or jsonPath to the erroneous field.

this sounds mostly like a validation approach, where you are validating 
the request and then have a specific point where validation failed. 
while this is something that can happen, the question is whether this is 
general enough to warrant a specific field. problems can occur for many 
reasons, and validation is just one part of that.

if such a field was added, the best way to do it might be a fragment 
identifier, because the media type of the request could be anything, and 
maybe the most general way to point to something might be a fragment 
identifier.

> Other than adding additional info to "more", is there any consideration
> for multiple problems in one response?  For instance, there may be more
> than one problematic field in a request.  It would be advantageous to
> report them all at once instead of piecemeal.  Perhaps a subProblem
> field or array that contains additional problems?

again, that sounds a lot like being very validation-oriented. the idea 
is to report HTTP-level problems, not so much validation messages about 
specific fragments where the requests caused validation problems. if 
this kind of validation and reporting resulting errors is what you want 
to do, the "more" is probably the way to go.

> Has anyone written a bit of client code for this yet?

nothing generic that i am aware of, but we're using it in specific 
client code. and maybe it's a bit early for broader adoption because the 
format is still evolving. mark probably can chime in here.

cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: Erik Wilde <[email-masked]>
Date: Thu, 14 Mar 2013 15:17:54 -0700

hello ray.

> 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 bot…

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?!…

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.