Re: poe

On Tue, 29 Mar 2005, Stefan Eissing wrote:

>
> I'd like to comment on 
> http://www.ietf.org/internet-drafts/draft-nottingham-http-poe-00.txt from the 
> perspective of a HTTP client/server implementor. I like POE. It's an 
> excellent idea. With my HTTP client lib hat on, I'd like to poke some holes 
> in the current draft:
>
> Chapter 3 and 4 introduces the POE-Links and POE headers and I got the 
> impression that these were designed with an end user application (like a 
> browser) in mind.
>
> 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).

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

> 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" :) ).

> Static Pages:
>
> Some HTML pages and forms will be served static, e.g. for performance 
> reasons. The question then is how the POE-Links header gets populated. Using 
> META tags in the page is a crutch, as the POEness of the POST resource 
> depends on the target application, not on the static page. The target app may 
> run on another server or be owned by another company etc. It might implement 
> POE on even days...
>
> 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.

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."