Re: poe

Am 29.03.2005 um 22:45 schrieb Yves Lafon:

> On Tue, 29 Mar 2005, Stefan Eissing wrote:
>
>>
>> POE-Links:
>>
>> The client receives information on a GET which are used in a 
>> subsequent POST (resp. error handling of it). The idea seems to be 
>> that a) these 2 requests are done against the same version of the 
>> server and b) that the error handling code has the information from 
>> the GET when analyzing the POST response.
>
> I would disagree,  POE-Links: makes no restriction on the target URI, 
> so it can be on another host. Even if the GET and the POST(s) are on 
> the same server, they might not be under the same "domain of control" 
> anyway...
> For b), consider POE_Links as a hint for the library.
>
>> This feels clumsy to me. I would prefer the error handling code 
>> *inside* the HTTP client lib to be able to recover from a lost POST 
>> response. So, on a lost POST response, the client could initiate an 
>> OPTIONS request (first thing which came into my mind) and discover 
>> that the POST resource was indeed a POE resource. Then it can resend 
>> the POST or GET the correct response without the client application 
>> noticing the recovery.
>
> Actually I think that a paranoid client SHOULD send an OPTIONS before 
> reissuing a POST, and a POE-compliant MUST NOT reply with POST in the 
> Allow: header if a POST has been successfully processed (processed, 
> regardless of the status of the reply).

You'd still like to find out about the POEness of the resource. If it 
still allows POST, the clients needs to know what it means.


>> POE:
>>
>> I do not claim to understand the purpose of this header. It is 
>> optional, so the server cannot really deduce any semantics of the 
>> client code by its absence. IMHO, to ensure predictability and 
>> robustness, a POE resource on a server should not vary its behaviour 
>> in the presence or absence of that header. But what is it good for 
>> then?
>
> If you have a POE version 2 that adds regex in the syntax of 
> POE-Links, then it indeed useful.

How can a version 2 client then find out that the server is on version 
1?

>> HTTP Caching:
>>
>> I am not sure if HTTP caching will get in the way or needs to be 
>> disabled if dealing with HTML resources. The server could Vary its 
>> response based on the POE client header, but vary is a pain with IE. 
>> So, it is probably best to always send POE-Links on these pages. 
>> Another reason for POE request header gone?
>
> As POE-Links have to be followed once, the pages you obtain via GET 
> should not be cacheable, unless you have a particular application of 
> this in mind ("be the first to click on this" -> fail -> "too late 
> buddy" :) ).

You are right. POE links on static pages are not really that useful.

>> This is my view from HTTP lib implementation. To sum it up:
>> - POE could enable HTTP libs to improve recovery on POSTs
>> - Applications (not libs) which care about POEness should be able to 
>> discover it, e.g. using OPTIONS (or another feature) against the 
>> POST-resources.
>
> If the OPTIONS reply is added, then the lib might want to retry 
> automatically, otherwise, it should be up to the application to decide 
> if a retry has to be attempted or not.

Agreed.

Cheers, Stefan

Received on Wednesday, 30 March 2005 17:05:12 UTC