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

Re: poe

From: i ahmed <ahmedat@gmail.com>
Date: Wed, 13 Apr 2005 00:54:59 +0500
Message-ID: <d8e1eb2905041212544fa25ff@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Stefan Eissing <stefan.eissing@greenbytes.de>, HTTP Working Group <ietf-http-wg@w3.org>

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/

On Apr 6, 2005 9:05 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 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 Tuesday, 12 April 2005 19:55:20 GMT

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