- From: James M Snell <jasnell@gmail.com>
- Date: Sat, 20 Oct 2012 19:05:25 -0700
- To: Mark Baker <distobj@acm.org>
- Cc: Steve Battle <steve.battle@sysemia.co.uk>, ietf-http-wg@w3.org, public-ldp-wg@w3.org
- Message-ID: <CABP7RbfFHiAiKZLQ8iTepJZSLjEvs7SwmdXma_SyKuQHchuEyA@mail.gmail.com>
Granted, there may be implementations that have issues with it.. I'm basing this off the language in the latest httpbis draft ( http://datatracker.ietf.org/doc/draft-ietf-httpbis-p2-semantics)... Specifically... <snip> If the request has a Content-Location header field, then the sender asserts that the payload is a representation of the resource identified by the Content-Location field-value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by HTTP). The information might still be useful for revision history links. ... 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 originall y 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. ... 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. </snip> As with everything tho, YMMV... - James On Sat, Oct 20, 2012 at 6:57 PM, Mark Baker <distobj@acm.org> wrote: > On Wed, Oct 17, 2012 at 11:18 AM, James M Snell <jasnell@gmail.com> wrote: > > I would say this is certainly a reasonable and logical assumption. Note, > > however, that you need to account for the possible presence of the > > Content-Location header within the POST request. If the POST includes a > > Content-Location, it's value effectively establishes the base URI. > > I wish :) See the discussion associated with this issue; > > http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i80 > > Mark. >
Received on Sunday, 21 October 2012 02:06:15 UTC