[oslc-core] Issue with Compact Rendering of a deleted (410) resource

[John Arwe]

<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-0001.html>