- From: i ahmed <ahmedat@gmail.com>
- Date: Wed, 13 Apr 2005 00:54:59 +0500
- 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 UTC