W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2005

Re: poe

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 6 Apr 2005 09:05:28 -0700
Message-Id: <3c4144a46cd69b0984966cf40d7efe25@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Stefan Eissing <stefan.eissing@greenbytes.de>

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:

>
> 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     http://www.mnot.net/
Received on Wednesday, 6 April 2005 16:05:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:40 GMT