2006/1/29, James M Snell <[EMAIL PROTECTED]>: > (Tim, please forgive me for using a few quotes from our chat.. it's > easier than paraphrasing) > > [TB]: In fact, I suspect an APP validator ought to emit warnings when it > sees a relative URI, it's probably a symptom of an error > [TB]: Just thinking out loud... at ongoing, the pictures and so on for > an entry always go into the same directory as the entry so I can always > say <img src="foo.jpg"/>. > [TB]: But if I were using APP I'd have to post the image, then put the > full URI in the article text.
…or simply POSTing a multipart/relative entity and have the server do what's appropriate… > [TB]: BUT... a smart publishing system might well decide to peek at the > incoming text, particularly if you have type="xhtml", and relativize URIs. > [TB]: Anyhow, it's actually conceivable that we should have spec text > saying "No particular base URI can be assumed in the body when you're > POSTing to create new content". +1 Relative IRIs in POSTed content –relative to the POST Request-URI– wouls work only if: - the server stores the entry with an IRI that don't change the relative IRI meaning (e.g. the collection's IRI is "/collection/" and the entry is stored at "/collection/entry") - the server processes relative IRIs to change them from "relative to the collection IRI" to "relative to the entry IRI" We can't enforce servers to follow the IRI-scheme described above or process every relative IRIs (especially in type="html" content or extension elements; or with other content type, e.g. Open Document or Flash or SVG documents), so clients shouldn't POST entities using relative IRIs. > [TB]: On the other hand, when you're updating with PUT, no problemo. +1 However, how to deal with the Content-Location header? If the server sends you a Content-Location header in response to the GET to retrieve the entry, what should a client do? given that "The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases." Should the APP prohibit the use of Content-Location? (-1, because the GET could be content-negotiated and the server SHOULD then return the Content-Location ; I'm willing to use "direct access" for GET in my implementation and let Apache do The Right Thing) or should the APP enforce servers to process Content-Location in PUT requests in the case they send such headers in response to GET requests? or should servers ignore Content-Location headers and treat IRIs relative to where the entry will be saved (e.g. GET /entry returns Content-Location: /entry/index.atom ; when POSTing an Atom Entry to /entry, that same server should treat IRIs relative to /entry/index.atom) or should the APP say nothing? -- Thomas Broyer
