Re: poe

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

Received on Friday, 1 April 2005 11:57:20 UTC