Re: poe

FYI, I've put some notes about OPTIONS support in current 
implementations here:

The most immediate problem I found was a long-standing bug in Apache's 

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

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

Mark Nottingham

Received on Wednesday, 6 April 2005 16:05:35 UTC