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

From: Nathan <[email-masked]>
Date: Tue, 12 Oct 2010 00:02:06 +0100

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.

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

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

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?

Best,

Nathan

Doc quotes:

  "Header fields in a PUT request that are recognized as representation
   metadata SHOULD be applied to the resource created or modified by the
   PUT.  Unrecognized header fields SHOULD be ignored." [1]

  "The following header fields are defined as representation metadata:
     Content-Encoding         ; Section 6.5
     Content-Language         ; Section 6.6
     Content-Location         ; Section 6.7
     Content-Type             ; Section 6.9
     Expires                  ; [Part6], Section 3.3
     Last-Modified            ; [Part4], Section 6.6" [2]

  "The Link entity-header field provides a means for serialising one or
   more links in HTTP headers." [3]

[1] 
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-11#section-7.6
[2] 
http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-11#section-4.1
[3] 
http://tools.ietf.org/html/draft-nottingham-http-link-header-10#section-5
[4] http://dev.w3.org/2006/waf/access-control/#syntax

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Oct 2010 14:56:48 +0200

> 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

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

> specifically Access-Control-Expose-Headers.

No idea. Anne?

> am very glad to see it in there, but have to double-check that this is

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

---

From: Nathan <[email-masked]>
Date: Tue, 12 Oct 2010 22:51:28 +0100

Julian Reschke wrote:
> (<http://tools.ietf.org/html/rfc2068#section-19.6.1>)

What's the status of the LINK and UNLINK methods? I'm aware PATCH has 
been put through standards track under RFC 5789, is there an effort to 
do the same for LINK and UNLINK?

I guess what I'm saying is that since 2068 has been obsoleted by 2616 
which doesn't define them, and since we're now approaching HTTP-Bis 
which again doesn't define them, is it still 'ok' to use LINK and UNLINK 
when the network scale awareness (perhaps) isn't there? (caches may not 
be invalidated etc)

As an aside, would there be scope to redefine them in HTTP-Bis, or would 
this need done under separate RFC as done with PATCH - etc, sure you 
follow my line of questioning :)

Thanks for your reply Julian,

Best,

Nathan

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Oct 2010 09:19:25 +0200

On 12.10.2010 23:51, Nathan wrote:
> ...

Nothing I'm aware of, but you're not the first one to ask.

> when the network scale awareness (perhaps) isn't there? (caches may not

Of course it's ok. LINK/UNLINK continue to be defined by a Proposed 
Standards.

> follow my line of questioning :)

I think this would require a new RFC.

That being said, I'd like to encourage you to seriously consider the 
other alternative I mentioned (PROPPATCH).

Best regards, Julian

---

From: Nathan <[email-masked]>
Date: Wed, 13 Oct 2010 08:40:41 +0100

> other alternative I mentioned (PROPPATCH).

Will do, and thanks for your continued help Julian,

Best,

Nathan