Re: poe

On Mar 31, 2005, at 1:10 AM, Stefan Eissing wrote:

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

OPTIONS is clearly the best approach, because a POST failing is an 
exceptional condition.

Since OPTIONS is problematic (I just re-checked Apache 1.3 and 2.0 CGI 
-- see [1]; to the best of my knowledge, neither ASP nor PHP gives any 
control of OPTIONS responses either; can someone attest to this? What 
about IIS CGI?), another approach would be to do a GET when POST fails, 
and look for a header that declares the POEness of the resource.

The problem I see with this is that, for the forseeable future, most 
resources accepting POST will not be POE resources, and having all of 
those GETs may prove problematic; although GET isn't *supposed* to have 
any side effects, many toolkits do offer similar semantics on POST and 
GET.

This is what led me to the current design.

In my implementation, I plan to keep a list of POE-Links that I've 
seen, removing a URI once I've successfully POSTed to it. Because I 
don't anticipate having a large number of requests going through the 
library (i.e., its use will be application-scoped), I don't think this 
will be unmanageable, although I imagine I'll offer a purge_poe_links() 
method, just in case.

It sounds like your use case is much higher-volume, perhaps with a 
broader application, or several applications using one component that 
can't differentiate between application contexts.

If that's the case, couldn't you have the application hand the library 
both the URI to deference, as well as a flag that indicates whether 
it's a POE resource? As long as previous requests have returned the 
http headers, the application should be able to handle this.

E.g.,

uri_resolver = URIResolver()
response = uri_resolver(method='GET', uri='http://www.example.com/')
poe_links = response.headers.get("POE-Links", [])
# application magic here, leading to a post
basket = my_magic_to_get_the_basket_link(response)
basket_is_poe = basket in poe_links
response = uri_resolver(method='POST', uri=basket, poe=basket_is_poe)

This approach has the nice quality that if there are hints in the body 
(e.g., XML or HTML attributes) that tell the app that the link is to a 
POE resource, it can use that information.


1. http://issues.apache.org/bugzilla/show_bug.cgi?id=15242

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

Received on Friday, 1 April 2005 02:53:11 UTC