From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Fri, 27 Apr 2007 10:17:09 -0400

On Apr 27, 2007, at 2:05 AM, Stefan Tilkov wrote:

> On Apr 27, 2007, at 3:51 AM, Dhanji R. Prasanna wrote:
>
>> Stefan, not to be pedantic but do you mean *get* request headers
>> and *set* response headers? Is there a case for reading (already-
>> written) response headers? Just curious what use cases might drive
>> how we expose the headers.
>
> I was really only thinking about getting request headers and
> setting response headers. I can imagine that some filter might want
> to set some "derived" headers, and once there's a chain of such
> filters it might make sense for them to work even for headers that
> have been set in a preceding filter ... but I agree this really
> seems to be out of scope.
>
With the sketch2 APIs you can access request headers in one of two
ways, either use @HeaderParam to access a single header value or use
HttpHeaders to access the set as follows:

@HttpMethod
public Foo getFoo(@HttpContext HttpHeaders headers) {...}

You can also use a class field instead of a method parameter.

To set response headers you use Response:

public Response getBar() {
   return Response.noContent().header(name1, value1).header
(name2,value2);
}

The plan is to have specific setters for common headers and have the
"header" method as an escape hatch for any header.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.