On Mar 14, 2008, at 11:30 AM, Stephan Koops wrote:
> Hi Marc,
>> Brainstorming media types I think we need:
>>
>> application/xml
>> application/atom+xml - should we leave this to Atom toolkits ?
>> application/svg+xml
>> application/json
>> application/x-www-form-urlencoded
>> application/octet-stream
>> text/plain
>> text/html
>> text/xml - include or just have application/xml ?
>>
>> +/- ?
> Yes, sounds good. What about application/xhtml+xml
OK.
>
>> For HTTP headers I propose ignoring those we already have helper
>> methods for in HttpHeaders or Response/ResponseBuilder (like
>> Cookie, If*, etc):
>>
>> General Headers:
>> Transfer-Encoding
>>
>> Request Headers:
>> Accept-*
>> Authorization
>> From
>> Host
>> User-Agent
>>
>> Response Headers:
>> WWW-Authenticate
>>
>> Entity Headers:
>> Content-* (excluding Location, MD5 and Range)
>> Expires
>>
>> +/- ?
> Do you want to include the listet headers or made them available?
Not sure what you mean - I was suggesting we add constants for the
headers I listed above.
>
> I think we should hide the authentication headers (Authorization and
> WWW-Authenticate), because authentication should be managed by the
> runtime environment, if I remember right.
I think ideally the container/runtime would handle those headers but I
wondered if some applications would want to manage authentication
themselves. I don't have a strong preference on this one.
>
>>>> Add response codes to Response class?
>>> I think Response.OK or Response.NOT_FOUND is not very good.
>>> Status.OK resp. Status.NOT_FOUND is better (or ResponseStatus.OK
>>> resp. ResponseStatus.NOT_FOUND or also Response.Status.OK resp.
>>> Response.Status.NOT_FOUND)
>> I like Response.Status.XXX.
> +1
>> For status codes I'd propose we don't include every possible status
>> code, just those an application is likely to use:
>>
>> 200, 201, 202, 204
>> 301, 303, 304, 307
>> 400, 401, 403, 404, 406, 409, 410, 412, 415
>> 500, 503
>>
>> +/- ?
> Why not 300 (Multiple Chices, http://tools.ietf.org/html/rfc2616#section-10.3.1)
> ?
I didn't think this would be used much, I'd expect a server just to
pick something suitable rather than return a list of possibles.
>
> Is 401 needed? The authentication is fully moved to the container,
> or do I miss something?
>
Same comment as for auth headers - don't have a strong preference but
thought it might be useful for apps managing their own auth.
Marc.
> While thinking about status 403:
> What about a method SecurityContext.forbidIfNotInRole(String...)
> which throws status 403, if the user does not is in at least one of
> the given roles?
> To allow the app developer to add his own Response data, there could
> also be a method SecurityContext.isUserInOneOfRoles(String...)
> returning a boolean, so that the app developer can create it's own
> Response.
> We could also add a method SecurityContext.userInNoRole(String...)
> that returns null or a ResponseBuilder with status 403, which the
> app developer could enrich as he want (own entity or what ever).
> This is analog to Request.evaluatePreconditions(..)
> Another possibility is to manage this with an annotation containing
> the roles which at least one is needed. But this complicates the
> algorithm "matching request to respone method"
>
> best regards
> Stephan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.