Subject: poe

From: Stefan Eissing <[email-masked]>
Date: Tue, 29 Mar 2005 10:34:44 +0200

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

---

From: Yves Lafon <[email-masked]>
Date: Tue, 29 Mar 2005 22:45:48 +0200 (MEST)

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

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

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 30 Mar 2005 19:04:48 +0200

Am 29.03.2005 um 22:45 schrieb Yves Lafon:

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

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.

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

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

> automatically, otherwise, it should be up to the application to decide 
> if a retry has to be attempted or not.

Agreed.

Cheers, Stefan

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 30 Mar 2005 15:52:59 -0800

Hi Stefan,

Thanks very much for the feedback. Responses below...

> impression that these were designed with an end user application (like 

Not really; I'm working on a Python HTTP library for use in 
inter-application communication, more than end-user browsers. Not to 
say that it wouldn't be useful to have support in browsers eventually, 
of course.

> the POST or GET the correct response without the client application 

While that's a nice, clean approach, the problem is that in most server 
implementations (e.g., Apache) it's difficult if not impossible for 
average users to handle OPTIONS with, for example, a CGI script. That's 
a key target for me.

I did POE this way because I *didn't* want to address the Web metadata 
discovery question; I've tried before [1][2] and it's a much bigger 
problem that what I'm trying to address here.

In the draft, I tried to emphasise that the headers were just one 
optional way of doing it. If a better way of discovering and 
communicating Web metadata comes along and gets broad adoption, nothing 
in POE prevents it from being used; all I've described here is a 
low-cost way to do it in the meantime.

> in the presence or absence of that header. But what is it good for 

Requiring that supporting clients send this header is unrealistic. 
Effectively, this header gives clients a way to say "I support POE; do 
something with that information if you like."

For example, a server may decide to include instructions / warnings 
about retrying POST requests in human-readable form if the client 
doesn't say it supports POE (such things are common); if the client 
says it supports POE, such warnings are unnecessary.

> Another reason for POE request header gone?

"Vary is a pain with IE" -- please explain?

I originally had some guidance about caching in the draft, but realised 
that there were no hard rules; in some cases, caching pages that link 
to POE resources is desirable. I could see adding some cautionary text, 
however; in the common case, I agree that caching shouldn't be allowed.

I don't see how it follows that this is a reason for getting rid of the 
request header.

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

If I read you correctly, you're saying that it's sometimes inconvenient 
to vary the URI of the POE resource appropriately, especially when the 
linking page is static, or the link crosses administrative domains.

I did get some early reviews that wondered about the feasibility of a 
regex or similar facility in POE-Links, so that the header wouldn't 
have to be customised for every response. My thoughts were that because 
the links in the document need to be changed pretty dynamically, the 
amount of work to also vary the POE-Links is trivial; i.e., there 
aren't many situations where the content is static *and* the POE-Links 
header needs to be dynamic.

Additionally, it seems to me that a regex facility could get people 
into trouble if they weren't careful (think of the unintended retries).

I see that there is a co-ordination problem between domains, but I 
think this can be addressed by giving each foreign domain a separate 
name space in the identifiers of the POE resources.

In other words, if a site called "Bob's Shopping Carts" gets linked to 
by two other sites -- let's call them Joe and Mary -- using Bob's 
services, and they want to do cross-domain POSTs, Bob could partition 
it out like this;
   http://bob.example.com/joe/
   http://bob.example.com/mary/
so that both Joe and Mary have two different areas where they can talk 
about unique resources, without clashes and without further 
co-ordination with Bob. Thus, if they both had (potentially different) 
customers named Jim, the resources would look like:
   http://bob.example.com/joe/customer/jim/123
   http://bob.example.com/mary/customer/jim/123

Overall, though, I wonder how prevalent cross-domain POSTs are, because 
of security concerns. Anyone have any statistics?

Does that answer your concern?

1. http://www.w3.org/TR/urispace.html
2. http://lists.w3.org/Archives/Public/www-talk/2002JanFeb/0015.html

--
Mark Nottingham     http://www.mnot.net/

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 31 Mar 2005 11:10:47 +0200

Mark,

thanks for the detailed response. I reply inline.

Am 31.03.2005 um 01:52 schrieb Mark Nottingham:

> [...]
> While that's a nice, clean approach, the problem is that in most 
> server implementations (e.g., Apache) it's difficult if not impossible 
> for average users to handle OPTIONS with, for example, a CGI script. 
> That's a key target for me

Ok, I misread chapter 2 that it also talks about Allow header in 
OPTIONS responses.

> communicating Web metadata comes along and gets broad adoption, 
> nothing in POE prevents it from being used; all I've described here is 
> a low-cost way to do it in the meantime.

Fair enough. I was looking for a way to addd POE support to my HTTP 
client lib. With the current draft I fail to see (that may be my 
personal failure) how to do it. I do not want to collect POE-Links 
headers from GET responses. My library is heavily used in a server 
environment with thousands of users and I cannot collect these headers 
for an undetermined amount of time.

So, my particular lib has to rely on discovering the POEness of a 
resource in order to support it *after* the POST response has failed. 
That disqualifies any additions to the POST response from the CGI 
script, since it is exactly that response that does not arrive.

Don't get me wrong. I have no concerns about POE. I would like to 
support it. It may be that my application domain is outside the playing 
field of POE. But maybe the collected brains here can come up with a 
solution that easily extends POE to be application for "my" use cases 
as well.

> "Vary is a pain with IE" -- please explain?

See http://archive.apache.org/gnats/4118
As far as I know, its still relevant in current IE versions.

[...]
> Overall, though, I wonder how prevalent cross-domain POSTs are, 
> because of security concerns. Anyone have any statistics?

Probably not high enough to worry about. Yours and Yves responses 
convinced me that cross domain posts and static content (caching) do 
not really matter for POE applications.

Cheers, Stefan