Subject: PaceServiceError

From: Tim Bray <[email-masked]>
Date: Wed, 03 Nov 2004 21:35:07 -0800

I'm feeling positive about PaceServiceError, but I have a question: why  
does it need to use a new custom-built HTTP verb?  Why don't we just  
specify that you POST to the ServiceError URI two name-value pairs, CGI  
style, either in the URI or the body?

Name        Value
resource    the URI where the problem is
problem     free-text description of the problem, no markup

e.g. POST with no body to  
http://example.com/service/error?name=http://example.com/feed/ 
315135&problem=not%20well- 
formed,unbalanced%20tag%20line%2041%20col%20118

  -Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 04 Nov 2004 07:53:49 +0100

> style, either in the URI or the body?

I think a new HTTP method gives us more than routing this message through  
POST. To err something is not equivalent of posting, and without a method  
for this, you can't err different resources, but have to err an URI with  
reference to the resource that is erronous. So instead of:

   ERR /feed.atom

you need to do something like this:

   POST /cgi-bin/error.cgi
   Content-Type: application/x-www-form-urlencoded
   Content-Length: 53

   error-document=/feed.atom&description=Ill-formed+XML

I don't think the second example is either simpler, more elegant or more  
RESTful than the first. Quite the opposite, actually.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 07:33:37 -0500

> style, either in the URI or the body?

It uses a new a verb so you can't screw up the XML on purpose and send 
requests to random POST handlers. Using a new verb means that the 
resource actually has to be an Atom error handler. This is important 
because the requests could be fired off automatically, from behind 
firewalls, etc. It's important that it be no more dangerous than img @src.

I have no opinion on the value of information sent along with the 
request, but I'll note that some Atom Protocol implementations send back 
responses that look like this:

<error>You've screwed up!</error>

Robert Sayre

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 4 Nov 2004 08:20:03 -0500

On Thu, 04 Nov 2004 07:33:37 -0500, Robert Sayre <[email-masked]> wrote:
> firewalls, etc. It's important that it be no more dangerous than img @src

I'm not sure I understand. Are you saying that of these
two requests, the first one is 'safer'?

----------------------------------------------
ERROR /errorhandler HTTP/1.1
Content-Type: application/atom+xml

<?xml version="1.0" encoding='iso-8859-1'?>
<error>Something bad happened.</error>
----------------------------------------------

----------------------------------------------
POST /errorhandler HTTP/1.1
Content-Type: application/atom+xml

<?xml version="1.0" encoding='iso-8859-1'?>
<error>Something bad happened.</error>
----------------------------------------------

    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 08:34:02 -0500

> two requests, the first one is 'safer'?

I didn't mean that a custom verb would result in a "safe method." I 
meant I'm not enthusiastic about defining a distributed, XML 
parser-triggered proxy mechanism for POSTing to an arbitrary URI.[0]

Robert Sayre

[0] http://imc.org/atom-syntax/mail-archive/msg05568.html

---

From: Graham <[email-masked]>
Date: Thu, 4 Nov 2004 13:35:28 +0000

On 4 Nov 2004, at 12:33 pm, Robert Sayre wrote:

> resource actually has to be an Atom error handler.

????

Graham

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 08:52:33 -0500

>> resource actually has to be an Atom error handler.

HTTP/1.1 200 OK
Content-Type: application/atom+xml
Atom-Error: http://example.com/manager/admin
<?xml version="1.0" encoding="UTF-8"?>
<feed>
...
<entry>...</entry>

POST /manager/admin HTTP/1.1

Robert Sayre

---

From: Graham <[email-masked]>
Date: Thu, 4 Nov 2004 13:52:45 +0000

> parser-triggered proxy mechanism for POSTing to an arbitrary URI.[0]

But why do you think ERRing to an arbitrary URI is safer?

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 4 Nov 2004 06:32:49 -0800 (PST)

> POST /manager/admin HTTP/1.1

I still don't get it. How does using a new HTTP method
somehow prevent whatever problems you claim exist by
using POST. Also you need to do a better job of
explaining what these supposed problems are. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #222
I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!"

__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 4 Nov 2004 09:30:13 -0500

> parser-triggered proxy mechanism for POSTing to an arbitrary URI.[0]

How do the terms 'proxy'  and 'arbitrary URI' apply to the
description given in http://www.intertwingly.net/wiki/pie/PaceServiceError ?

    -joe

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 09:44:39 -0500

> description given in http://www.intertwingly.net/wiki/pie/PaceServiceError ?

"Proxy" applies in the general sense of the word, rather than the 
HTTP-specific one. By "Arbitrary URI", I mean a different URI than the 
resource that contains the error. None of the hierarchical semantics of 
HTTP URIs are used to constrain possible acceptable values for the ErrorURI.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 04 Nov 2004 14:52:20 +0000

Dare Obasanjo wrote:

>>>>It uses a new a verb so you can't screw up the
>>
>>XML on purpose and send 
>>
>>>>requests to random POST handlers. Using a new
>>
>>verb means that the 
>>
>>>>resource actually has to be an Atom error
>>
>>handler.
>>
>>>
>>>????
>>
>>HTTP/1.1 200 OK

I could see an argument as follows

  - Error notification semantics are sufficiently crisp or distinct 
  that they are justified in being broken out from POST*.

  - Only servers built with this HTTP extension in mind will need to 
  deal with it (for now that's Atom aware. but over time we should 
be wary about calling it an "Atom method")

  - Intermediaries, such as security applications, can reason about 
the method independent of other things going through POST.

- Any caching subtleties can be reasoned about independent of POST.

Nonetheless, my main issue is bifurcation of resources** into those 
that know about ERR and those that don't. Unless the case is 
cast-iron I think it hurts Atom adoption to be extending HTTP like 
this. Finally, that case probably needs to incorporate a solid 
argument that doing error notifs over POST is not just broken or 
inelegant, but harmful.

cheers
Bill

* This is where Mark Baker and I will not start a sidethread about 
POST's genericism ;)

**  Only web services wankers worry about services.

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 4 Nov 2004 09:58:45 -0500

> HTTP URIs are used to constrain possible acceptable values for the ErrorURI.

Ok, so neither of those words adds any to the description
and your explaination of them has not in any way clarified
to me what you see as a problem here.

What exactly do you see as a problem with using 
POST and how does using ERROR fix it?

    -joe

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 10:04:08 -0500

> explaining what these supposed problems are. 

Let's see. It's tough to make an exhaustive list, because POST is used 
for all sorts of things, many of which are not idempotent 
(PaceServiceError is), and the list of purposes its used for grows every 
day.

Cross-site scripting would be a good one.

1.) Evil person finds naive PHP script out there on the net.
2.) Evil person manipulates honest clients into POSTing to it by giving 
them bogus XML.
3.) PHP script bombarded with POSTs from random clients. Using a new 
verb makes it likely that a 405 would result.

Also, I'd like to note that the Pace doesn't say anything about a body 
for the request. It's just a hit counter.

Robert Sayre

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 4 Nov 2004 10:26:46 -0500

> 2.) Evil person manipulates honest clients into POSTing to it by giving

How, exactly, is evil person stopped from 
sending an ERROR but yet they can send a POST?

> verb makes it likely that a 405 would result.

A DOS, or even DDOS attack is just that, an attack, and all 
of the methods under discussion here are all equally vulnerable
to that. All the methods avoid using GET which allows a really
simple img/@src method of triggering such a DDOS attack.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 10:28:49 -0500

Tim Bray wrote:

> 
> Having read the eight follow-ups, I'm really unconvinced.  I'm pretty 
> sure that if I were malicious and wanted to DOS some Atom 
> implementation, there are easier ways than what you propose.   And 

It's not about DOSing an Atom implementation. It's about exploiting any 
HTTP server with an insecure POST handler through an Atom client. Using 
POST for PaceServiceError is completely irresponsible.

 > inventing new HTTP verbs is really questionable.

That's the subtext of all the arguments for POST, I think. 
Unfortunately, it's not really backed by anything other than religion. 
It's also humorous to me that most of the people who feel that way have 
no problem with inventing new verbs by extending HTTP with custom headers.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 10:20:29 -0500

Bill de hÓra wrote:

> 
> Nonetheless, my main issue is bifurcation of resources** into those that 
> know about ERR and those that don't. Unless the case is cast-iron I 
> think it hurts Atom adoption to be extending HTTP like this. 

I don't understand what you mean by "bifurcation". Almost all resources 
have a limited number of supported methods. The case is cast-iron, 
because POST is used with completely variable non-idempotent semantics. 
Its advocates can never prove their case.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Thu, 04 Nov 2004 07:21:42 -0800

On Nov 4, 2004, at 4:33 AM, Robert Sayre wrote:

>> why  does it need to use a new custom-built HTTP verb?  Why don't we 
>> just  specify that you POST to the ServiceError URI two name-value 
>> pairs, CGI  style, either in the URI or the body?
>
> requests to random POST handlers

On balance, I'm -1 on PaceServiceError with a new HTTP verb. -Tim

---

From: Julian Reschke <[email-masked]>
Date: Thu, 04 Nov 2004 16:59:11 +0100

> inventing new HTTP verbs is really questionable.

What's so questionable about it?

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Walter Underwood <[email-masked]>
Date: Thu, 04 Nov 2004 07:57:28 -0800

--On Thursday, November 4, 2004 7:33 AM -0500 Robert Sayre <[email-masked]> wrote:
> requests to random POST handlers. Using a new verb means that the resource
> actually has to be an Atom error handler.

The second sentence is wrong. Anyone can implement ERROR. It is an HTTP
method, not an Atom method. We should expect other implementations.

If we want an Atom-only HTTP method, then we should call it ATOMONLYERROR.
Or maybe we can namespace-qualify it.

Changing the name doesn't really protect bad implementations of POST
handlers. Those need to check their inputs, like any other code.

I strongly favor POST over a new HTTP method. Post has existing 
semantics and parameter-passing formats. Relying on those makes
our spec smaller and implementations easier. Defining those anew
for Atom makes the spec bigger and implementations harder.

POST should also make QA and load testing easier. Anybody got a
load tester that already implements ERROR?

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 4 Nov 2004 11:00:05 -0500

> POST for PaceServiceError is completely irresponsible.

Ok, I think, after 6 or 7 follow-ups I think I finally see a problem.
Here is a scenario:

Malicious user X produces an Atom feed served with an 
X-Atom-Error header. 

Malicious user X could change their X-Atom-Error header to point
to someone elses URI (it could be /their/ Error URI or it could
be a completely different service). Either way Malicious user 
X then intentionally forces their Atom feed to be invalid, thus
causing all the subscribers to X Atom's feed to hit that
unrelated service.

Am I understanding the scenario correctly?

> That's the subtext of all the arguments for POST, I think.

No, the subtext was you didn't explain yourself very well.

    -joe

---

From: Danny Ayers <[email-masked]>
Date: Thu, 4 Nov 2004 17:21:20 +0100

Personally I'm still unsure how ERROR would be any less responsible
than using POST, but even if I were convinced, then there are still
other issues.

> Unfortunately, it's not really backed by anything other than religion.

Religion isn't idempotent. The more people follow the religion, the
less the chance of your (heretical) suggestions being accepted. The
orthodoxy at the moment is that adding HTTP verbs is a bad idea.
Whether this underlying belief is true or not, it renders it virtually
impossible to add HTTP verbs across the board (c.f. URIQA).

A more immediate problem is the need to make modifications at the HTTP
layer. That has practical implications, in particular as regards who
will be *able* to implement.

> no problem with inventing new verbs by extending HTTP with custom headers.

Hmm, arguably the custom headers act more like adverbs or adjectives,
but there are admittedly similar implementation issues.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Mark Baker <[email-masked]>
Date: Thu, 4 Nov 2004 11:31:48 -0500

FWIW, I'll just repeat my previous statement about these error specs.
IMO, the issue is that the whole concept of farming out functionality to
untrusted parties for tests that need to be trusted (i.e. done by the
publishing tool itself), is fundamentally flawed.  Nobody will use it.

-1 to both error paces.

Also FWIW, in case one does go through, I'd normally suggest just using
POST, but if it's the case that Atom resources which already accept POST
also need to be able to accept error reports, then due to a deficiency
in HTTP (lack of mandatory extensions, and the lack of a standard means
for declaring extended intentions), I consider ERR/ERROR a reasonable
option.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

---

From: Tim Bray <[email-masked]>
Date: Thu, 04 Nov 2004 08:32:30 -0800

> causing all the subscribers to X Atom's feed to hit that

Of course, for this to work, Mr. Malicious has to have built up enough 
subscribers to his feed to cause a problem.  And in this case, he would 
quickly be caught, it would be totally traceable.  Consider the case of 
my feed, with maybe 10,000 subscribers of whom more are coming through 
Bloglines all the time.  How much main could I inflict?  Quite a lot 
actually, if I put my mind to it, but not by Atom ServiceError hacking. 
  -Tim

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 04 Nov 2004 16:29:34 +0000

> Unfortunately, it's not really backed by anything other than religion. 

Not true, Robert. In this case, the argument presented for ERR 
hasn't be compelling enough, technically or otherwise. Stepping back 
a bit, I see nothing that requires us to spec out a new HTTP method 
for such a feature. I do believe we're making things hard for 
ourselves for little benefit.

> no problem with inventing new verbs by extending HTTP with custom headers.

On the whole I don't think it's up to me to be convincing people who 
want new verbs against them - that's backways.

Also (and this is *not* directed at you Robert), arguing that a verb 
is generic because the HTTP responses to the fact of it not 
generally being deployed are uniform is certainly incoherent and 
very probably specious. I won't be going down that particular 
rathole again.

cheers
Bill

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 4 Nov 2004 08:46:28 -0800 (PST)

> for the request. It's just a hit counter.

So let me get this straight. 

Some cracker hacks a high traffic site such as
http://www.slashdot.org, borks their feed and alters
their Atom-Error header to point to some site he
doesn't like. Your argument is that it will be less
load on the site to reject ERROR requests than to
process then reject POST requests. 

That's like arguing that getting hit by a truck going
60MPH is worse than getting hit by a car going 60MPH.
In the long run you still end up dead. 

If anything your are making a good argument against
PaceServiceError as a whole not whether the HTTP
method should be POST or some brand new ERROR method.  

=====

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 11:54:38 -0500

> process then reject POST requests. 

No, that's not my argument, but yes, it would be, if the resource 
accepts POSTs for other reasons.

You have no idea what POST does on a given URI. It's not a question of 
traffic, it's a question of whether a random POST handler results in 
state changes that depend on the number of times it's been hit. Since 
the semantics of POST are application-specific (which is fine, IMHO), 
the POST handler could be doing something irreversible, like sending 
email or firing missiles. The request in PaceServiceError is idempotent.

It doesn't need to be a high-traffic site at all.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 12:07:23 -0500

Bill de hÓra wrote:

> 
> Not true, Robert. In this case, the argument presented for ERR hasn't be 
> compelling enough, technically or otherwise. 

The request in PaceServiceError must be idempotent.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 13:10:52 -0500

I'm -1,000,000 on using POST for this feature. Too bad, but since Atom 
is so open I'm free to try it without the approval of this WG.

Walter Underwood wrote:
> semantics and parameter-passing formats.

POST doesn't have any semantics. It's application specific. The protocol 
even uses POST to DELETE in the SOAP part.

> Relying on those makes
> our spec smaller and implementations easier.

New methods aren't hard to do. This is just FUD.

> Defining those anew

No, it makes this feature insecure and opaque.

> load tester that already implements ERROR?

Writing a switch statement at the method level is harder than writing a 
switch statement to figure out what POST *really* means? Nah.

Who in the world would use a load tester that doesn't let you configure 
every aspect of the request. How else will you know how your server 
reacts to methods it doesn't support?

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 13:14:57 -0500

Graham wrote:
> On 4 Nov 2004, at 4:54 pm, Robert Sayre wrote:
> 
> "Firing missiles"
> No way is posting an Atom Error going to cause anything worse than an 
> invalid arguments type response page. You are mental Mr Sayre.
> 

I may be mental, but it would also be mental to claim to know the 
security level of every post handler out there. Nobody seems to grasp 
the security implications of this feature anyway, so I doubt it will be 
implemented well. Let's just drop it.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Thu, 4 Nov 2004 18:00:50 +0000

"Firing missiles"

Graham

---

From: Danny Ayers <[email-masked]>
Date: Thu, 4 Nov 2004 19:43:19 +0100

> implemented well. Let's just drop it.

We do know that feed quality is an issue with existing syndication
systems. This feature may help. Why don't we try it provisionally in
the next spec revision? If there are any technical difficulties or a
missile crisis, we simply drop it again.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 4 Nov 2004 10:40:56 -0800 (PST)

> implemented well. Let's just drop it.

I wonder what you're going to argue next. Maybe it'll
be the fact that a malicious Atom server can use
existing HTTP redirect responses to send clients to
other sites and invoke URIs that have side effects. 

Oh my God!!! What do we do??? We must abandon HTTP... 

=====

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 13:51:08 -0500

> Oh my God!!! What do we do??? We must abandon HTTP... 

You'll find that the common behavior for a redirect from a POST is to 
send a GET.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 4 Nov 2004 10:58:07 -0800 (PST)

> You'll find that the common behavior for a redirect

You'll also find that it is common behavior for GET
requests to have side effects. Even Bloglines so
called RESTful API is full of GET requests that have
side effects. 

=====

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 14:04:18 -0500

> called RESTful API is full of GET requests that have

I know. PaceServiceError used GET until last time we talked about it, 
when people wanted made all sorts of irrational arguments about GET.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Thu, 04 Nov 2004 11:52:19 -0800

> is so open I'm free to try it without the approval of this WG.

Well, on reflection, it seems to me that, while I still don't believe 
that GRUMBLE really brings much of a security pay-off, on reflection it 
doesn't add any significant costs, so I can live with PaceServiceError 
as written.

And I do think it would be a net plus for Atom to have a non-compulsory 
error-reporting built-in. -Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 04 Nov 2004 21:17:53 +0100

On Thu, 4 Nov 2004 09:58:45 -0500, Joe Gregorio <[email-masked]>  
wrote:

> What exactly do you see as a problem with using POST and how does using
> ERROR fix it?

If you can't see the answer to this question, how come you can see it when  
replacing 'ERR' (not 'ERROR', imho) with 'PUT' or 'DELETE'?

To be clear: How is PUT or DELETE more necessary than ERR for the given  
functionality they give? Why is it okay to squeeze ERR requests into POST,  
but not PUT or DELETE?

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 4 Nov 2004 15:40:50 -0500

> replacing 'ERR' (not 'ERROR', imho) with 'PUT' or 'DELETE'?

Could you please stop getting your knickers in twist
and just answer the question.

I am asking a simple question in that I don't yet fully
understand the point Robert is trying to make. If you 
feel you can do a better job please jump right in.

    -joe

---

From: Henry Story <[email-masked]>
Date: Thu, 4 Nov 2004 21:50:23 +0100

Cool! :-)

I have not been following this discussion for more than a few months, 
as I have been really busy with Atom-OWL. I thought it had died out 
completely.

I am +1 on something like PaceServiceError, with the idea of turning it 
perhaps into an Internet Draft if that is possible. It seems to me to 
be a very generic HTTP addition that could well be of use all over the 
web.

I would prefer the method to be called ERR or ERROR over GRUMBLE, 
because it is well understood in software engineering that functions 
can return error codes.

Also I prefer the simplicity of ERRing the resource itself, and nothing 
else. That removes the need for an extra header for every response and 
really simplifies the mechanism of reporting the error: The client, in 
its error report, just needs to send back to the resource the exact 
same request it used in its GET, POST, PUT or DELETE, +perhaps some 
extra information such as the time of the original request and the 
method of the original request.

I see that Atom could be fixing a very big problem on the web by 
demonstrating how this is done, especially if it does it in such a way 
that it is completely generic, and so easily added to every other web 
app out there.

Henry Story

On 4 Nov 2004, at 20:52, Tim Bray wrote:

>> I'm -1,000,000 on using POST for this feature. Too bad, but since 
>> Atom is so open I'm free to try it without the approval of this WG.
>
> that GRUMBLE really brings much of a security pay-off, on reflection 
> it doesn't add any significant costs, so I can live with 
> PaceServiceError as written.
>
> And I do think it would be a net plus for Atom to have a 
> non-compulsory error-reporting built-in. -Tim
>

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 16:03:14 -0500

> Am I understanding the scenario correctly?

Yes, and the effect of hitting that unrelated service is unknowable. The 
operation must be idempotent to be implemented responsibly.

Robert Sayre

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 4 Nov 2004 16:36:04 -0500

> operation must be idempotent to be implemented responsibly.

Thank you. Now that I understand the point you are trying 
to make I agree that using POST for this is inappropriate.

Actually, just a minor correction on your nomenclature,
the term you should use is 'safe', not 'idempotent', when
describing the effect:

    http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1

I did read Tim Bray's response that it won't be that many 
hits and that the culprit would soon be found out, but that
assumes a pretty dumb Malicious user X. What if the feed is
only served intermittently with bad X-Atom-Error header? Or
only served that way to certain aggregators? And don't tell
me no one would ever do that, I've actually done something 
similar myself by serving a different RSS file based on the 
User Agent. Not for malicious reasons mind you, but it
was very easy to do.

You will note that it is still possible, if PaceSericeError 
is adopted today, that mischief will still be possible
since I can still get *your* server to be pinged as having
an invalid feed by *me* tweaking my X-Atom-Error header
and then intentionally invalidating my own feed.

What can we do?

The only solution that I can see right now that avoids all
of these problems is that the ERROR method be used
and that it only be used on the URI of the feed itself. 
I.e. if you get any of the error conditions in the Pace
then the client sends the ERROR method back to the 
URI from which is retrieved the Atom feed. 

Benefits:

1. Very simple.
2. Obviates the need for the X-Atom-Header completely.
3. Can't be used in any of the malicious ways outlined above.
4. Since we aren't worried about cross-site usage we can
   go back and add in a request body that describes the
   problem in more detail.

Disadvantages:

1. A whole new method. 
2. More difficult to implement on the server side depending
    on how your site is implemented. I.e. it /is/ possible to 
    accept an ERROR method on a statically served file
    and redirect it to a CGI to handle the request,
    but that requires some mod_rewite magic in your
    .htaccess file.

This is the only workable solution I can see
right now that avoids the above problems. I hope
someone else has a better idea because I'm
not terribly fond of the idea based on the difficulty
that may be faced in implementing it. Also, inventing
new HTTP methods makes me slightly squeamish.

If we do this then I think it should be written 
as an I-D outside of this WG.
 
    -joe

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 4 Nov 2004 13:47:31 -0800 (PST)

> operation must be idempotent to be implemented

I'll note that there isn't much difference between
this scenario and Malicious user X just issuing HTTP
redirects to the unrelated service thus bypassing
Atom-Error header which is less likely to be supported
than HTTP redirects anyway. 

=====

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 16:50:07 -0500

>     http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1

I understand the distinction very well. I wanted to use GET and was told 
that the method wasn't safe because it gives up too much information 
about the client. I say idempotent is important because you will get the 
same response no matter what, and no signal that any request was 
accepted or processed.

> and then intentionally invalidating my own feed.

I don't follow your logic. I would just ignore hits from referrers I 
don't care about.

> URI from which is retrieved the Atom feed. 

Also, the utility of sending a request to the resource that's known to 
be busted could be nil.

Robert Sayre

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 4 Nov 2004 14:20:58 -0800

>than HTTP redirects anyway.

I agree with Dare. A malicious feed emitter can do pretty much 
equivalent damage in many ways.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 04 Nov 2004 23:33:32 +0100

> Also, the utility of sending a request to the resource that's known to  

In some cases, yes. But just because i.e. the XML is ill-formed, that  
doesn't mean the script that serves the XML document is completely broken.

Also, in many situations where the feeds are served dynamically, it's the  
same service that will receive the ERR as the one which is serving the  
feed. And since the service is the same, it doesn't matter whether you ERR  
the resource's URI or another one. It's simpler to just err the resource  
URI, though.

Also, if the client don't receive an expected result from the ERRed  
resource, it can maybe fall back to another ErrorURI (if defined at  
several levels). Just an idea.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 04 Nov 2004 23:24:05 +0100

> and that it only be used on the URI of the feed itself.

I've thought this is the best solution all along, so I'm needless to say;  
+1 on this. It would be nice to be able to ERR a different URI, though,  
since not all feeds are served by something that can do anything with an  
incoming ERR request but still would want to (e.g. static files).

The general and recommended practice should be to ERR the erronous  
resource, but another mechanism should be available, imho. What we can do  
to restrict the usage on the ErrorURI is to say that it MUST be in the  
same domain as the erronous resource. If the domain in the URI of the  
'X-Error-URI' header is different from the domain in the URI of the  
resource, the client MUST NOT do an ERR request to the URI.

> If we do this then I think it should be written as an I-D
> outside of this WG.

I think so as well.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 17:40:16 -0500

> equivalent damage in many ways.

I don't understand what Dare is saying. How do I get someone to send a 
POST with a redirect? Dare's response was that some GETs are unsafe... 
ok fine, but not really the same problem.

Robert Sayre

---

From: Henry Story <[email-masked]>
Date: Fri, 5 Nov 2004 00:19:57 +0100

I also agree that the the following methods are probably quite 
compatible, and could each be used, in a certain default order perhaps:
	- A response header specifying the location of an error URI
	- ERRing the resource itself

On 4 Nov 2004, at 23:33, Asbjørn Ulsberg wrote:

>
> On Thu, 04 Nov 2004 16:50:07 -0500, Robert Sayre 
> <[email-masked]> wrote:
>
>> Also, the utility of sending a request to the resource that's known 
>> to be busted could be nil.
>

I would like to add here that the fact that the resource may be broken 
won't stop the ERR message reaching the correct destination.

It will probably rarely be the resource itself that deals with the ERR 
message itself. Currently if you send such a message to an Apache web 
server, it will simply log a message in its log file. Similarly a 
slightly more intelligent web service would be able to send the 
messages for specific groups of urls to log files readable by the owner 
of the resources.

The ERR message is a flag that something is wrong with the resource. 
That can be useful information not just for the process that created 
the resource, but for all the caches along the way. It may be these 
caches after all that may have corrupted a perfectly good initial 
response. Automatically sending the response to some third URI is in 
that respect less RESTful.

>
> Also, in many situations where the feeds are served dynamically, it's 
> the same service that will receive the ERR as the one which is serving 
> the feed. And since the service is the same, it doesn't matter whether 
> you ERR the resource's URI or another one. It's simpler to just err 
> the resource URI, though.
>

Henry

---

From: Henry Story <[email-masked]>
Date: Fri, 5 Nov 2004 00:24:13 +0100

+1
This will help us find out how well such a system works. It it does, it 
will help client writers and server writers tune their implementations 
more quickly.

Henry

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 4 Nov 2004 15:27:23 -0800 (PST)

> ok fine, but not really the same problem.

Your argument is full of assumptions. 

(1) Sending GET requests to an arbitrary URI is much
more dangerous than sending arbitrary POST requests. 

(2) Redirecting a POST request will mean that data
won't get POSTed to the new URI. Please go read
http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html,
HTTP specs just say the user must not be automatically
redirected. I've seen the behavior of web browsers
after redirection on a POST and this has never stopped
me from sending the POST message. 

Basically I think you've unhealthily fixated on this
"problem" when worse problems exist with the entire
usage of XML over HTTP for delivering Atom feeds. 

=====

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 18:39:50 -0500

Dare Obasanjo wrote:
> (1) Sending POST requests to an arbitrary URI is much
> more dangerous than sending arbitrary GET requests. 
> 

It is. That's why we have different HTTP methods.

> me from sending the POST message. 

I don't understand your point. What's the series of requests that will 
lead to an automatically redirected POST request?

> usage of XML over HTTP for delivering Atom feeds. 

Thanks for looking out for my health.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Fri, 05 Nov 2004 11:19:44 +1100

> I don't follow your logic. I would just ignore hits from referrers I

referrers? 

what are the expected uses of the Referer header with this thing?

the Pace describes use of a 410 GONE response once the error had been fixed
... is it proper http behaviour to vary the response (200 OK vs 410 GONE)
for a given specific URI according to the Referer header value?

e.

---

From: Martin Duerst <[email-masked]>
Date: Fri, 05 Nov 2004 08:59:35 +0900

If this is Atom-specific, and it gets a verb, then rather than
using "ERR", it should be called "ATOMERR" or some such.

Regards,    Martin.

---

From: steve jenson <[email-masked]>
Date: Thu, 4 Nov 2004 16:44:30 -0800

> for a given specific URI according to the Referer header value?

Also, it shouldn't be a 4xx code if it's not an error.

-steve

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 20:09:14 -0500

>> for a given specific URI according to the Referer header value?

That's not what the Pace says. The Pace says you can change the ErrorURI 
for a given feed whenever you want. I would probably change the value of 
the of the ErrorURI every time the feed was generated.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Fri, 05 Nov 2004 12:29:10 +1100

> the of the ErrorURI every time the feed was generated.

still doesn't help, unless you want to eliminate proxy caches.

client A requests feed X via proxy P
server S generates feed with errorURI E
client A receives feed X with errorURI E
client B requests feed X via proxy P
proxy P provides feed X with errorURI E

both client A and client B have on hand the same errorURI.

client A sends a ERR response to URI E
server S fixes whatever was broken

client B sends a ERR response to URI E
server S does what?

e.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 20:47:13 -0500

> still doesn't help, unless you want to eliminate proxy caches.

False.

> client B sends a ERR response to URI E

Well, server S reports success it if it wants to use the same ErrorURI. 
If not, it can send an error. What's the problem here? The server 
decides whether a URI is bound to a resource.

Is your problem that the server is still receiving ERRORs after the 
problem has been fixed? That's just an accurate reflection of reality. 
You'll stop getting those when people stop receiving your busted feed.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Fri, 05 Nov 2004 13:11:51 +1100

>> still doesn't help, unless you want to eliminate proxy caches.

sorry, I must have misunderstood you -- I thought you said you would change
the errorURI to prevent two or more clients receiving the same errorURI,
thus avoiding the problem of having to respond to those reports (since a
given client shouldn't report to the same URI more than once).

(If that is not the reason for you changing the errorURI each time, then
just what is your reason for doing so?)

All this based on your assertion that the pace doesn't say what I claimed...

> That's not what the Pace says.

Which is odd, since the pace says this:

> 5.6.4.3 410 
> 
> The server is no longer accepting error reports to this URI, and will not
> resume accepting reports in the future. The client SHOULD NOT send any further
> requests to this URI.

and then follows that with an extended example illustrating just that.

It might also pay to backtrace on this thread, which started with you

>>> for a given specific URI according to the Referer header value?

(I'm still interested in the generic HTTP answer to that question, btw)

So Robert, say your server receives a GRUMBLE to your ErrorURI, and say you
have already fixed the problem, and say the referer header is some
third-party URI ... just what response will you provide to the request?

> problem has been fixed? That's just an accurate reflection of reality.

That's not my question (nor my problem). My question was is it http-proper
to vary the response depending on the referer header. What's the answer to
that question, and this time lets not get distracted by red herrings like
changing the ErrorURI.

e.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 04 Nov 2004 21:33:33 -0500

> third-party URI ... just what response will you provide to the request?

204. I won't record it, but I will acknowledge it. GRUMBLE doesn't 
guarantee that the request changes state on the server.

> that question, and this time lets not get distracted by red herrings like

Oh, that's not what I meant by "ignore it". If it's a valid request to a 
URI where errors are still being accepted, you'll get a 204.

Robert Sayre

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 05 Nov 2004 14:04:29 +0100

> using "ERR", it should be called "ATOMERR" or some such.

I don't think it should be Atom-specific. I'd actually add a vote to move  
this into its own I-D.