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

Re: poe

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 30 Mar 2005 15:52:59 -0800
Message-Id: <e641f801bdc318770ae52509c9f2a456@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Stefan Eissing <stefan.eissing@greenbytes.de>

Hi Stefan,

Thanks very much for the feedback. Responses below...

On Mar 29, 2005, at 12:34 AM, Stefan Eissing wrote:

> Chapter 3 and 4 introduces the POE-Links and POE headers and I got the 
> impression that these were designed with an end user application (like 
> a browser) in mind.

Not really; I'm working on a Python HTTP library for use in 
inter-application communication, more than end-user browsers. Not to 
say that it wouldn't be useful to have support in browsers eventually, 
of course.

> POE-Links:
> The client receives information on a GET which are used in a 
> subsequent POST (resp. error handling of it). The idea seems to be 
> that a) these 2 requests are done against the same version of the 
> server and b) that the error handling code has the information from 
> the GET when analyzing the POST response.
> 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.

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.

> POE:
> I do not claim to understand the purpose of this header. It is 
> optional, so the server cannot really deduce any semantics of the 
> client code by its absence. IMHO, to ensure predictability and 
> robustness, a POE resource on a server should not vary its behaviour 
> in the presence or absence of that header. But what is it good for 
> then?

Requiring that supporting clients send this header is unrealistic. 
Effectively, this header gives clients a way to say "I support POE; do 
something with that information if you like."

For example, a server may decide to include instructions / warnings 
about retrying POST requests in human-readable form if the client 
doesn't say it supports POE (such things are common); if the client 
says it supports POE, such warnings are unnecessary.

> 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?

I originally had some guidance about caching in the draft, but realised 
that there were no hard rules; in some cases, caching pages that link 
to POE resources is desirable. I could see adding some cautionary text, 
however; in the common case, I agree that caching shouldn't be allowed.

I don't see how it follows that this is a reason for getting rid of the 
request header.

> Static Pages:
> Some HTML pages and forms will be served static, e.g. for performance 
> reasons. The question then is how the POE-Links header gets populated. 
> Using META tags in the page is a crutch, as the POEness of the POST 
> resource depends on the target application, not on the static page. 
> The target app may run on another server or be owned by another 
> company etc. It might implement POE on even days...

If I read you correctly, you're saying that it's sometimes inconvenient 
to vary the URI of the POE resource appropriately, especially when the 
linking page is static, or the link crosses administrative domains.

I did get some early reviews that wondered about the feasibility of a 
regex or similar facility in POE-Links, so that the header wouldn't 
have to be customised for every response. My thoughts were that because 
the links in the document need to be changed pretty dynamically, the 
amount of work to also vary the POE-Links is trivial; i.e., there 
aren't many situations where the content is static *and* the POE-Links 
header needs to be dynamic.

Additionally, it seems to me that a regex facility could get people 
into trouble if they weren't careful (think of the unintended retries).

I see that there is a co-ordination problem between domains, but I 
think this can be addressed by giving each foreign domain a separate 
name space in the identifiers of the POE resources.

In other words, if a site called "Bob's Shopping Carts" gets linked to 
by two other sites -- let's call them Joe and Mary -- using Bob's 
services, and they want to do cross-domain POSTs, Bob could partition 
it out like this;
so that both Joe and Mary have two different areas where they can talk 
about unique resources, without clashes and without further 
co-ordination with Bob. Thus, if they both had (potentially different) 
customers named Jim, the resources would look like:

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

Does that answer your concern?

1. http://www.w3.org/TR/urispace.html
2. http://lists.w3.org/Archives/Public/www-talk/2002JanFeb/0015.html

Mark Nottingham     http://www.mnot.net/
Received on Thursday, 31 March 2005 00:02:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:26 UTC