poe

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.

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.

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?

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?

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.

Best Regards, Stefan

Received on Tuesday, 29 March 2005 08:34:50 UTC