Re: Which headers to apply from a PUT request (Link?)

On 12.10.2010 01:02, Nathan wrote:
> Hi,
>
> I'm looking for a quick bit of guidance on whether the Link header would
> class as representation metadata and thus should be applied to a
> resource created/modified by a PUT request.

The Link header spec says "entity header", which is the terminology we 
used in HTTPbis until draft 10; so I think it's supposed to fall into 
the same class as "Content-Language", for example.

> If so great, if not then how would one update the value of a Link header
> via HTTP?

The tricky part is of course that PUT *replaces*, so do we expect a PUT 
request without Link header fields to remove them?

Alternatives are LINK/UNLINK 
(<http://tools.ietf.org/html/rfc2068#section-19.6.1>), or PROPPATCH 
(after defining a canonical representation of links into href-typed 
WebDAV properties).

> Secondly, I'd like to ask the same about CORS response headers [4],
> specifically Access-Control-Expose-Headers.

No idea. Anne?

> And finally, I've noticed that Content-Location is a representation
> metadata header, thus `SHOULD be applied to the resource created or
> modified by the PUT` - I certainly have a use-case for this myself and
> am very glad to see it in there, but have to double-check that this is
> correct?

Did you check 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-11.html#rfc.section.6.7.p.6>:

"If Content-Location is included in a request message, then it MAY  be 
interpreted by the origin server as an indication of where the user 
agent originally obtained the content of the enclosed representation 
(prior to any subsequent modification of the content by that user 
agent). In other words, the user agent is providing the same 
representation metadata that it received with the original 
representation. However, such interpretation MUST NOT  be used to alter 
the semantics of the method requested by the client. For example, if a 
client makes a PUT request on a negotiated resource and the origin 
server accepts that PUT (without redirection), then the new set of 
values for that resource is expected to be consistent with the one 
representation supplied in that PUT; the Content-Location cannot be used 
as a form of reverse content selection that identifies only one of the 
negotiated representations to be updated. If the user agent had wanted 
the latter semantics, it would have applied the PUT directly to the 
Content-Location URI.

A Content-Location field received in a request message is transitory 
information that SHOULD NOT be saved with other representation metadata 
for use in later responses. The Content-Location's value might be saved 
for use in other contexts, such as within source links or other metadata."

?

Best regards, Julian

Received on Tuesday, 12 October 2010 12:57:28 UTC