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

Re: poe

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Thu, 31 Mar 2005 11:10:47 +0200
Message-Id: <46c8c56e50eaead73bfff35f502685b8@greenbytes.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Mark Nottingham <mnot@mnot.net>

Mark,

thanks for the detailed response. I reply inline.

Am 31.03.2005 um 01:52 schrieb Mark Nottingham:

> Hi Stefan,
>
> Thanks very much for the feedback. Responses below...
>
> On Mar 29, 2005, at 12:34 AM, Stefan Eissing wrote:
> [...]
>> This feels clumsy to me. I would prefer the error handling code 
>> *inside* the HTTP client lib to be able to recover from a lost POST 
>> response. So, on a lost POST response, the client could initiate an 
>> OPTIONS request (first thing which came into my mind) and discover 
>> that the POST resource was indeed a POE resource. Then it can resend 
>> the POST or GET the correct response without the client application 
>> noticing the recovery.
>
> While that's a nice, clean approach, the problem is that in most 
> server implementations (e.g., Apache) it's difficult if not impossible 
> for average users to handle OPTIONS with, for example, a CGI script. 
> That's a key target for me

Ok, I misread chapter 2 that it also talks about Allow header in 
OPTIONS responses.

> I did POE this way because I *didn't* want to address the Web metadata 
> discovery question; I've tried before [1][2] and it's a much bigger 
> problem that what I'm trying to address here.
>
> In the draft, I tried to emphasise that the headers were just one 
> optional way of doing it. If a better way of discovering and 
> communicating Web metadata comes along and gets broad adoption, 
> nothing in POE prevents it from being used; all I've described here is 
> a low-cost way to do it in the meantime.

Fair enough. 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.

Don't get me wrong. I have no concerns about POE. I would like to 
support it. It may be that my application domain is outside the playing 
field of POE. But maybe the collected brains here can come up with a 
solution that easily extends POE to be application for "my" use cases 
as well.

>
>> HTTP Caching:
>>
>> I am not sure if HTTP caching will get in the way or needs to be 
>> disabled if dealing with HTML resources. The server could Vary its 
>> response based on the POE client header, but vary is a pain with IE. 
>> So, it is probably best to always send POE-Links on these pages. 
>> Another reason for POE request header gone?
>
> "Vary is a pain with IE" -- please explain?

See http://archive.apache.org/gnats/4118
As far as I know, its still relevant in current IE versions.

[...]
> Overall, though, I wonder how prevalent cross-domain POSTs are, 
> because of security concerns. Anyone have any statistics?

Probably not high enough to worry about. Yours and Yves responses 
convinced me that cross domain posts and static content (caching) do 
not really matter for POE applications.

Cheers, Stefan
Received on Thursday, 31 March 2005 09:11:45 GMT

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