Subject: Re: poe

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 Mar 2005 18:53:07 -0800

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/

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 1 Apr 2005 13:56:44 +0200

Mark,

thanks for your suggestions. Adding poe options to the library is 
certainly one way of enabling support. But maybe the spec can given 
non-cgi application also a chance to add something to the protocol? See 
below.

Am 01.04.2005 um 04:53 schrieb Mark Nottingham:

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

How about this:

POE-Links in OPTIONS responses

Resources MAY return the POE-Links header in OPTIONS responses. POE 
resources SHOULD announce their poe-ness by sending

POE-Links: .

in response to OPTIONS requests. If no POE-Links header is seen in an 
options response, a client MUST NOT deduce anything about the poe-ness 
of the resource.

Cheers, Stefan

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 1 Apr 2005 14:03:08 -0800

I like the general approach; the language needs a little adjustment 
(the last sentence could be read in the wrong way); but I think the 
sentiment is "just because you don't get a POE-Links back on an 
OPTIONS, don't assume it isn't a POE resource," which seems right (if 
unfortunate -- it would be really nice to be able to ask a resource and 
get a definitive answer!).

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 Apr 2005 09:05:28 -0700

FYI, I've put some notes about OPTIONS support in current 
implementations here:
   http://www.mnot.net/blog/2005/04/03/options

The most immediate problem I found was a long-standing bug in Apache's 
mod_cgi:
   http://issues.apache.org/bugzilla/show_bug.cgi?id=15242

On Apr 1, 2005, at 3:56 AM, Stefan Eissing wrote:

> non-cgi application also a chance to add something to the protocol? 
> See below.
>
>>> 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.
>>
>> 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.
> [...]
>
> How about this:
>

---

From: i ahmed <[email-masked]>
Date: Wed, 13 Apr 2005 00:54:59 +0500

Hi Mark ,

Thanks very much for the feedback

Regards
------------------------------------
tel: -+ 9256498511
http://freeonlinework.netfirms.com/
http://www.geocities.com/free_online_chat_rooms/
http://www.geocities.com/my_free_online_games/