[oslc-core] Issue with Compact Rendering of a deleted (410) resource
John Arwe
johnarwe at us.ibm.com
Mon Oct 17 12:57:49 EDT 2011
<context>
4a. Client then goes to present the preview by creating an iframe setting
the @src to the URL from the previous step
Since http://example.org/thing is delete but the implementation GET
request asking for HTML using URL
http://example.org/preview?view=small&resource=http://example.org/thing
It is this implementation's response to return appropriate message,
right?
A client could be really careful and preform a HEAD on
http://example.org/thing to verify the resource is still there
This leads me to believe that this is not a spec issue but is an
interesting condition that would be good to highlight in some implementers
guide.
Does this make sense to you? Anyone else have any additional thoughts?
</context>
> A client could be really careful and preform a HEAD
This won't close the window, it will just narrow it. This is a series of
unserialized operations (with respect to the server, as is all of HTTP,
really), resources can disappear at any moment.
In this specific case where the server has the knowledge that the
resource's URL -used- to be valid (so the current output is 410 instead of
404), it would be kind of the server to provide friendly HTML (assuming
the browser displays it). In the case where the server implementation
does not maintain any "history" about "recently valid" URLs (so the client
would always get 404 instead of 410 for this case), the client code would
have to handle it. In this case where "the client code" ends up being
your browser, it may/not be worth the effort.
Best Regards, John
Voice US 845-435-9470 BluePages
Tivoli OSLC Lead - Show me the Scenario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20111017/85bb7527/attachment-0003.html>
More information about the Oslc-Core
mailing list