Subject: Proposal for an HTTP ERR method

From: Henry Story <[email-masked]>
Date: Wed, 23 Jun 2004 14:05:02 +0200

SUMMARY:
  There is currently an asymmetry in reporting errors between the client  
and the server. The server can return an error status to the client on  
its request, but the client cannot tell the server that it has returned  
an invalid response. This proposal rectifies this problem with a  
RESTful easily implementable and backward compatible solution to this  
asymmetry, by proposing a new ERR (ERROR) HTTP method to complement  
GET, POST, PUT, ...

BACKGROUND:
   The W3C is requiring strict adherence to many new standards. XML for  
example has to be well formed, and should be rejected if not. The well  
formedness of an XML response depends on the XML payload as well as the  
HTTP headers (such as mime types) that accompany the response. If these  
are broken, as can happen all to easily when a web server is improperly  
configured, the client has no simple and automatic way of notifying the  
resource that it is broken. For B2B applications this is not too much  
of an issue, as a lot of resources and many channels are available  
between the consumer of a resource and its producer. B2B has up till  
now been the main consumer of XML. In the consumer world the dynamics  
are very different, and will lead to a widening gap between  
specification and implementation. This is why this issue has appeared  
on the Atom mailing list[2]. But I believe the proposed solution to  
that problem can be generalised in such a way as to help the forces of  
standardisation across the whole web.

PROPOSAL:
Note this is a fledgling proposal, and will clearly need some growing  
up.

When a client receives a malformed server response it CAN (SHOULD?)  
notify the resource that it is broken, by sending a ERR request,  
identical in all ways except for the ERR method to the original  
request, plus a couple of extra ERR specific headers:

	-Error-Message: a human readable standard error message
	-Error-Code: A set of to be defined error codes that categorise the  
type of error
     -Error-Spec: A pointer to RFC document sections that explain the  
error
     -Error-Date: the date the request was initially sent
     -Error-Method: the method (GET, POST, ...) of the original request.
	-Error-ContentLength: the length of the human readable error text that  
could be the body of this message

ERR should probably be limited to certain specific types of errors,  
including things like broken XML, XML encoding incorrectly specified in  
the header, or other errors relating to well known RFC or specs. This  
is to be fleshed out...

EXAMPLE:

-------8<-------
GET /index.xml HTTP/1.x
Content-encoding: text/xml; charset=UTF-8
Accept: */*
Accept-Encoding: gzip, deflate;q=1.0, identity;q=0.5, *;q=0
Accept-Language: en-us, ja;q=0.62, de-de;q=0.93, de;
...

<?xml version="1.0" encoding="iso-8859-1" ?>
<pløtz/>
------->8-------

The response is broken though clearly interpretable. Clients (in the  
wider of Consumer2C or B2C) will therefore attempt to accommodate the  
standards due to market pressure. Market pressures are close to  
physical laws in their ferocity. We cannot change them. As a result  
more an more such breakages will occur, and the standards will be left  
in the dust of this vicious whirlwind.[1] In any case fighting against  
it is going to be very tiresome.

Much easier is to require clients to at least send an ERR response to  
the resources if they are going to bypass the standards.  If you allow  
us to imagine a future where resources are intelligent enough to fix  
themselves, we can see how this can help the web heal itself,  
automatically.

Here is an example of the clients message:

-------8<-------
ERR /index.xml HTTP/1.x
Content-encoding: text/xml; charset=UTF-8
Accept: */*
Accept-Encoding: gzip, deflate;q=1.0, identity;q=0.5, *;q=0
Accept-Language: en-us, ja;q=0.62, de-de;q=0.93, de;
Error-Message: XML is of incorrect content type
Error-Code: XXXX
Error-Spec: RFCXYZ,sec 3; RFCXXX, sec54
Error-Date:  Saturday 19 June 2004, 18:05:30 GMT (whatever encoding)
Error-Method: GET
Error-ContentLength: 63

The Mime type of the content was text/xml. This requires the content to  
be in ASCII format, but we found some UTF-8 characters in the message.
We could interpret the message at present but will not necessarily be  
able to do so in the future. Please refer to RFCXYZ, sec 3 and RFCXXX,  
sec54 for more information. These can be found at http://ietf.org/
------->8-------

ADVANTAGES:

1. RESTfulness

Proxies and other intermediaries can join in to make the Web a more  
standard place.

2. Backward compatible
This proposal could very well already work with the current web  
architecture, without any problem. I have tried it myself:

-------8<-------
hjs@bblfish:0$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
ERR /index.html HTTP/1.1
Host: bblfish.localhost
Message: invalid XML

HTTP/1.1 501 Method Not Implemented
Date: Sat, 19 Jun 2004 10:10:37 GMT
Server: Apache/1.3.29 (Darwin)
Vary: accept-language,accept-charset
Allow: GET, HEAD, OPTIONS, TRACE
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

14c
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>501 Method Not Implemented</TITLE>
</HEAD><BODY>
<H1>Method Not Implemented</H1>
ERROR to /index.html not supported.<P>
Invalid method in request ERROR /index.html HTTP/1.1<P>
<HR>
<ADDRESS>Apache/1.3.29 Server at bblfish.local Port 80</ADDRESS>
</BODY></HTML>
------->8-------

Clearly this is not the response we want in a web that has adopted this  
proposal, but it already has the correct side effect: namely it adds an  
error message in my apache error log:

-------8<-------
[Sat Jun 19 12:10:45 2004] [error] [client 127.0.0.1] Invalid method in  
request ERROR /index.html HTTP/1.1
------->8-------

Apart from that of course it correctly informs the client that the ERR  
message is not available, and so that sending further such requests is  
pointless.

3. This proposal avoids the vicious circle that other workarounds  
require: namely a file somewhere that specifies where to send error  
reports, this file itself perhaps being malformed.

4. The resource to which ERR is sent is known to be alive, since it  
just responded to the request. The ERR can furthermore be sent as part  
of the same tcp connection.

REFERENCES

This came out of a discussion on the atom mailing list.

[1] originally proposed here:
        http://www.imc.org/atom-syntax/mail-archive/msg05112.html
[2] a concise explanation for the need for the ERR method:
        http://www.imc.org/atom-syntax/mail-archive/msg05146.html
[3] a long discussion on #rdfig where I try to respond to all the  
questions thrown at me by Danny Ayers  
http://www.ilrt.bris.ac.uk/discovery/chatlogs/rdfig/2004-06 
-19.html#T14-48-59
[4] a Page on the Atom wiki that may be kept up to date on this issue:
	   http://www.intertwingly.net/wiki/pie/PaceErrVerb

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 23 Jun 2004 09:09:42 -0600 (MDT)

On Wed, 23 Jun 2004, Henry Story wrote:

> If you allow us to imagine a future where resources are intelligent
> enough to fix themselves, we can see how this can help the web heal
> itself, automatically.

If something is smart enough to fix itself, it is most likely smart
enough to test itself, instead of relying on a client to do the
testing. It is also probably smart enough not to trust test results
from untrusted clients.

> reports, this file itself perhaps being malformed.

I do not see a conceptual difference in the above context: Both "a
file somewhere" and "a some HTTP method" are bug-reporting interfaces.
Both can be badly broken by a given implementation. And, on this
planet, both would require some human intervention to fix the problem.

> just responded to the request. The ERR can furthermore be sent as
> part of the same tcp connection.

AFAIK, there is usually no inter-transaction state in HTTP. The ERR
request is not guaranteed to reach the originator of the broken
response, even if the same Request-URI is used. TCP connections do not
help here because they are hop-by-hop.

It is also not clear how the client can determine the true origin of
the error (not to mention connect to that true origin!).  Responses
are often generated (and, hence, corrupted) by multiple true origins
and/or by HTTP intermediaries or even things like ICAP or OPES
adaptation servers that may not even be HTTP-aware.

I am afraid there is no good technical solution here. It is a cultural
problem :-(.

Alex.

---

From: Henry Story <[email-masked]>
Date: Wed, 23 Jun 2004 17:58:34 +0200

[I am also cc ing this to atom-syntax, just so those that are 
interested there to continue this discussion can move it over here. A 
log of it can be found here:
http://lists.w3.org/Archives/Public/ietf-http-wg/2004AprJun/
]

On 23 Jun 2004, at 16:58, Jamie Lokier wrote:

> Henry Story wrote:
> What kind of malformed server response?
>
> Broken HTTP headers are comparatively rare and should probably get an
> ERR, except perhaps for the Server header.

Thanks. One more good reason for ERR. :-)

> Malformed HTML is very common.  Sending ERR in response to malformed
> HTML would generate a flood of ERRs.  But -- what is malformed HTML
> anyway?

Yes. Presumably HTML would not warrant an ERR. But XHTML might very 
well.

> XML and XHTML do have well defined specifications.
> I admit, that despite reading many documents and specifications,
> I hadn't realised that text/xml needed to use ASCII characters only.

Neither had I, nor most of the people on the atom mailing list. There 
is a HUGE thread there going on and on about that, which lead us to 2 
proposals to solve this issue, of which this is the more generally 
applicable one.

> To your example:
> That's a malformed request.
> 400 Bad Request is the correct server response :)

Thanks. I am sorry I wrote this all out a little too fast.
The request would be the following:

------------8<---------------------
GET /index.xml HTTP/1.1
Host: example.com
Connection: keep-alive
User-Agent: BlogEx
Accept: text/xml
-----------8<-----------------------

The response would be something like

------------8<---------------------
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/xml
Server: SomeServer/2.1
Content-Length: 55
Date: Wed, 23 Jun 2004 15:36:05 GMT

<?xml version="1.0" encoding="iso-8859-1" ?>
<pløtz/>
-----------8<---------------------

I will fix it right away on the wiki at:
http://www.intertwingly.net/wiki/pie/PaceErrVerb#preview

> [...] I can't see what character that is after the "l" and before the 
> "t".
> It appears as a box in my mailer.  (Emacs says it's character code
> 0x8f8 but I am suspicious).

It's a swedish o I think (the one with a line through it. So it is not 
ascii.

>
> It would be an easier fight if there were a central, high profile
> place where commonly needed implementation bugs and workarounds could
> be deposited -- and eventually removed a few years later when it's
> confirmed they're not required any more.

I imagine that in the body of the message (if one thinks it would be a 
good thing for ERR to have a body that is) one could have a URL that 
points to such a place. Perhaps a few will pop up as a result of 
creating such a method.

> Not sure if that would help or hinder the fight to get clean standard
> implementations out there,but it would certainly help with building
> interoperable code, and highlighting the problems of real 
> implementations.
> Name and shame, perhaps?

That can be something additional. But perhaps before shaming someone 
one should first alert them to the error of their ways.

> Again, why do you have a Content-Encoding header, and malformed at
> that, in the request?

Thanks for pointing that out. Get it right fixed.

> The XML file identifies itself as iso-8859-1.  Clearly it's intended
> that those bytes are understood as iso-8859-1 characters, not UTF-8
> characters.  A decent implementation would surely _either_ use the
> encoding declaration, when none appears in the Content-Type (i.e. the
> same as if "application/xml" were the content-type), or (conforming to
> RFC 2376) use us-ascii, and treat all the high byte characters as
> broken or single byte unexpected characters in a default encoding such
> as (so often the case) iso-8859-1?

I have to direct you to the huge thread that started this out on the
atom mailing list.
http://www.imc.org/atom-syntax/mail-archive/msg04656.html
Perhaps someone there can post a short resume of it.

>
> Also, shouldn't the text say US-ASCII as opposed to just ASCII? :)
>
>> ADVANTAGES:
>
> I quite like the idea.  Filling up logs of broken servers --
> excellent.  Perhaps you could take advantage of the Referer header to
> get a short message in there. :)

There should clearly be some good behavior rules.

> Note that some dubious servers ignore the method: they'll treat ERR
> the same as GET, or do even worse things.  (E.g. one server treats
> this request line as a GET of "HTTP/1.1": "ERR /GET HTTP/1.1", and
> treats this request as a GET of an empty URL: "ERR /index.html
> HTTP/1.1").

Interesting point. You can't do much about broken servers. They will 
slowly die out hopefully.

>
> So you might not want to send ERRs to servers which haven't solicited
> them.

Yes. One could request which methods a server supports before sending 
the ERR.
There is an HTTP method for that, OPTIONS I think.

> -- Jamie

Thanks a lot for the lengthy response. Looks like this is the right 
place to debate this proposal.

Henry Story
http://bblfish.net

---

From: Henry Story <[email-masked]>
Date: Wed, 23 Jun 2004 18:25:41 +0200

> testing. It is also probably smart enough not to trust test results

I am smart enough to test my code. I still find errors in it. Recently 
my nice OSX machine crashed. Apple tests its code as far as I know.
:-)

> planet, both would require some human intervention to fix the problem.

Fixing the problem will most probably require some human intervention.
But if you have just downloaded some broken XML and still have an open 
connection to the server, why not just send an ERR at that moment to 
the server. Then it can be clearly logged, and it is also clear what 
the problem is about.

> help here because they are hop-by-hop.

Well who-ever along the road gets the request will want to deal with 
it. If a cache receives the request for example it might decide to 
clear the document from its cache and re-fetch the page in case the 
problem has been fixed.

> adaptation servers that may not even be HTTP-aware.

The same problem exist for all of http. You cannot determine who
sent the response to you. So this is no more problematic than the other
methods. And whoever is sending you the bad xml should be notified.

If you are saying that your first request may have gone down one route, 
which returned you the bad xml, whereas your ERR went down another 
route which would have returned you good xml, then that is an 
interesting point.

How could one deal with that situation, if that situation indeed exists?

---

From: Justin Chapweske <[email-masked]>
Date: Wed, 23 Jun 2004 11:47:25 -0500

Why introduce a new unnecessary method when you could simply issue a
POST to some bug-reporting URI associated with the server?

If you're going to specify anything, submit a proposal to advertise
feedback URIs using a RESTful approach, perhaps in HTTP response headers
such as Link, or within the (x)html itself as a <link> tag.

-- 
Justin Chapweske - Founder, Onion Networks
http://onionnetworks.com/
651-340-8787
 
Transfer large files 10x faster than FTP with Onion Networks' WAN
Transport(tm).  http://onionnetworks.com/products_wantransport.php

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 23 Jun 2004 18:00:11 +0100

Henry Story wrote:
> Err. Sorry. I did not realise you had sent the mail to me only and not 
> also to the ietf list.

That's ok.  I intended to send it to the list as well, but slipped.
So you did me a favour :)

I will bounce my message to you to the list, with a modified To
header, so people know what you replied to and the thread makes sense
again.

-- Jamie

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 23 Jun 2004 11:08:47 -0600 (MDT)

On Wed, 23 Jun 2004, Henry Story wrote:

> I am smart enough to test my code. I still find errors in it.
> Recently my nice OSX machine crashed. Apple tests its code as far as
> I know. :-)

You said "intelligent enough to fix themselves". Now you are giving
examples of something fixing something else. These examples are out of
scope (i.e., they are irrelevant to the discussion).

Here is an in-scope example that illustrates my point: If I am smart
enough to wash my hands, I am smart enough to check whether they are
dirty (and an intelligent-enough machine would be even better at
that!). When/if machines are intelligent-enough to fix themselves, we
would not need other machines to inform them of bugs; these related
functions would be integrated).

> the server. Then it can be clearly logged, and it is also clear what

You said "avoids the vicious circle that other workarounds require". I
fail to understand how ERR proposal is conceptually different from any
other "bug-reporting interface" proposal as far as that "vicious
circle" is concerned. The fact that something can be logged does not
explain the difference to me. Something is logged/recorded with any
other "bug-reporting interface" proposal.

> clear the document from its cache and re-fetch the page in case the

OK. It seems to me that now, instead of proposing a

	Dear Server,
		The response you sent some time ago was
		broken for the following reasons: ...
		Please fix it.

protocol, you are proposing a

	To who it may concern:
		The response I have received some time
		ago is broken for the following reasons:...
		If you think you are somehow related
		to that response, please consider doing
		something about it.

protocol. Is my interpretation accurate?

> > It is also not clear how the client can determine the true origin
> > of the error (not to mention connect to that true origin!).
> > Responses are often generated (and, hence, corrupted) by multiple
> > true origins and/or by HTTP intermediaries or even things like
> > ICAP or OPES adaptation servers that may not even be HTTP-aware.
>
> sent the response to you. So this is no more problematic than the
> other methods.

Other HTTP methods do not followup/depend-on previous transactions
(and things break when they implicitly do).  Or are you talking about
other bug-reporting methods? If it is the latter, than what you seem
to be saying is that your method is at least as bad as others as far
as bug origin identification is concerned. I would agree with that!

> And whoever is sending you the bad xml should be notified.

The above argument is not about necessity/usefulness of
notifications. It is about locating the sender. If you cannot locate
the sender, it may be pointless to send notifications, unless you want
to broadcast them (which seems to be a different design from what you
originally documented).

> route which would have returned you good xml, then that is an

I was saying two things in the original two paragraphs above:
	- second request route may be different from the
	  first request route
	- the response may be created by many agents, some
	  of which may even be invisible to (unreachable from)
	  the recipient

I am afraid there is no good technical solution here. It is a cultural
problem: It is pointless to design a protocol to inform a machine that
something is broken if broken things "work OK" without being fixed.
And, vice versa, on a planet where broken things do not work, such a
protocol would probably not be needed as implementations would test
themselves to avoid being broken.

Alex.

---

From: Henry Story <[email-masked]>
Date: Wed, 23 Jun 2004 19:13:07 +0200

Whether this method is unnecessary is what we are trying to determine.

Is there a standard for finding a bug reporting uri? Because the Atom 
community is developing one [1]. And we would like to avoid every 
service having to re-invent error reporting, as this is keeping us off 
our task of specifying the Atom Syntax and API. Since every consumer of 
XML is faced with the ietf and w3c standards that state that one should 
*not* consume badly formed responses, everyone is going to need to be 
able to report errors if we don't want market pressures to lead us down 
the path of incompatible and broken implementations as html did.

The problem with having to find a specific error service uri, is that 
this requires one or more extra requests to other uri, many of which 
may themselves be broken. The advantage of ERR is that I don't need to 
know about any other URI to be able to notify it of the problem. I have 
already communicated with it, so I just need to notify it of the ERR.

There is currently a fundamental asymmetry in error reporting between 
the client and the server. Every request allows the server to report an 
error, but none allow the client to report an error back to the server. 
This is one reason this seemed like this proposal might help restore 
the imbalance.

Henry

[1] http://www.intertwingly.net/wiki/pie/PaceServiceError

---

From: Henry Story <[email-masked]>
Date: Wed, 23 Jun 2004 19:22:40 +0200

Sorry I should have responded in more detail to your alternatives.

> feedback URIs using a RESTful approach, perhaps in HTTP response 

Sounds like an idea. But if the HTTP header itself is broken...?

> such as Link, or within the (x)html itself as a <link> tag.

This one is less good, because you are asking us to read the body of 
the response, which may be broken.

Henry
http://bblfish.net/

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 23 Jun 2004 18:43:57 +0100

> my nice OSX machine crashed. Apple tests its code as far as I know.

I have to agree with Henry that the _principle_ of automatically
causing server errors, that are detected by good clients, to be logged
at the server is a good one.

However there's a danger that server logs will then fill due to
well-meaning but broken clients which _misreport_ bugs which aren't,
in fact, bugs.  Care is needed.

> route which would have returned you good xml, then that is an 

That situation _definitely_ exists.  Think of HTTP load balancers and
such.  POSTs for a URI may be handled by different servers than GETs
for the same URI.

I would think _most_ servers would route ERRs for a URI to the same
place that served that URI recently, _most_ of the time.

That is enough to alert humans to a problem on their servers, which is
being detected by clients.

> How could one deal with that situation, if that situation indeed exists?

You let the server administrators figure it out.

If server A is receiving error notifications, but server B is the
cause, then its up to the admins of server A to figure that out and
fix server B, or pass the information on to the owners of B.

> >I am afraid there is no good technical solution here. It is a cultural

I agree.  However there is presently a trend towards making both
clients and servers are tolerant as possible of bad input, and as good
as necessary but not much more output.  There's a mechanism for
alerting people about faulty client requests, and about faults which
are detected at the server: the server error log.  (The same problem
of misattribution applies here, as it could be an error introduced by
a faulty intermediary, however those kinds of logs are still very
useful).

The culture which arises is a natural result of who communicates error
information to whome.

Problems which are logged and visible are fixed.  Hence, clients
workaround broken servers and servers workaround broken clients.  Ok,
that makes for loose coding in parsers and such.  However, clients
which send the wrong thing are more likely to get fixed: because the
result of gross client transmission errors is seen at the client,
soon, by people who will fix it or hassle the people responsible for
the client.

Servers which send the wrong thing are less likely to get fixed:
because the result of gross transmission errors is less likely to be
communicated to the servers.  The clients see it, but the effort of
reporting bugs is such that the people responsible for the server are
not so likely to be informed of it.

This means that important bugs like grossly malformed XHTML will get
fixed at the server: the cost of reporting that kind of bug is low
compared with the benefit of fixing it - and XHTML is fairly well
defined, so that's a benchmark to meet.

But subtler protocol bugs, like the text/xml example and things like
bad protocol syntax and bad HTML (which is not always easy to define)
-- then it's easier to ignore the problem and implement a workaround
at the client, than it is to report problems to the people responsible
for the server.

It's really about ensuring that faults cause some kind of visible
problem -- either a real failure (usually that's not appropriate), or
something logged.  The better errors are detected and logged, provided
they are _real_ errors, not faulty detectors, then the more quickly
those get fixed.

It's true that server output errors should be detected with testing by
those responsible for the server.  But you cannot realistically devote
as many resources to that kind of testing as your client base can.

It's not perfect, but it would be an avenue for catching more errors
than the resources devoted to server-side self checking can.  (And we
know, in reality, that such checking is rarely done thoroughly, if the
server "seems to work".  Yet, responding to errors in logs is more
likely to be done, imho).

It's a bit like compiler warnings.  Compiling with gcc -Wall and then
fixing the code to eliminate the warnings is often helpful.

Btw, that raises a point: What about using the Warning header or one
like it?

For non-fatal client errors, a server could send the client a
"Warning: your client sent badly or inconsistently labelled XML, I
have guessed its encoding (utf-8), and may have guessed wrong; fix
your client".

Similarly, a client could send a warning with its _next_ request to
the same server.  "Warning: the previous response from this server
(foo.org [1.2.3.4] for GET /index.xml) sent badly or inconsistently
labelled XML; I have guessed its encoding (utf-8), and may have
guessed wrong; fix your server".

As Alex points out, that's not guaranteed to reach the same resource
as caused the error.  In fact it's less likely -- as the next request
is likely to be for a different resource.  But it will still cause
(potentially, if they're interested) the error to be logged at the
site, and humans will see it and can figure out what it means.

The ERR proposal has the disadvantage, compared with a Warning header,
that it causes more round trips, it will break some servers, which
aren't expecting ERR (and don't support OPTIONS either, even though
they advertise as HTTP/1.1), and it's asymmetric too: servers should
have a channel for sending non-fatal messages of this kind to clients,
just as clients can send these non-fatal messages to servers (they're
non-fatal by definition in the latter case, due to the stateless
nature of HTTP).

The Warning header, or another header chosen for this, does not suffer
from those problems. :)

-- Jamie

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Wed, 23 Jun 2004 19:46:43 +0200

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Henry Story
>Sent: Wednesday, 23 June 2004 19:23
>To: [email-masked]
>Cc: Justin Chapweske; Atom Syntax
>Subject: Re: Proposal for an HTTP ERR method
>
>

Why shouldn't ERR not be broken in this case?
IMHO, POST is more widely implemented and more likely to work correctly.
This would also speed implementation and correctness of the system. Why
reinvent the wheel when you can already use it?

If HTTP itself is broken, why actually use HTTP to report HTTP is broken?
This seems quite risky to me...

>This one is less good, because you are asking us to read the 
>body of the response, which may be broken.
>

To prevent annoying the wrong person, whenever possible. The responsibility
of the content might be with a different person than the responsibility to
keep the server alive.

- Joris

---

From: Justin Chapweske <[email-masked]>
Date: Wed, 23 Jun 2004 12:52:04 -0500

> You let the server administrators figure it out.

This would be another example why an explicit error reporting URI in the
response headers would be a better way to go.  The system could
dynamically include unique identifiers for the generating server and
include that in the URI, and perhaps have all URIs for a cluster of
servers point a single error reporting server.

Adding new HTTP methods should only be done when there is no other
sensible choice available.

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 23 Jun 2004 19:08:18 +0100

Alex Rousskov wrote:
> When/if machines are intelligent-enough to fix themselves, we

I agree :)

I think it's about getting the information to where it's most effective.

A server will never be as thoroughly tested by its own admins, nor by
future intelligent software, as it will be by the huge cloud of
diverse clients, each testing for things which the server people (and
those making test suites) haven't thought of.

When you're making mistakes at work, you try to fix them yourself.
But it is still helpful if, when other people notice, they tell you!

> other "bug-reporting interface" proposal.

I think the point is to make ERR automatic.
Any other automatic error reporting->logging system would do just as well.

"<p>Please send bug reports to <a
href='mailto:[email-masked]'>[email-masked]</p>" at the
end of each web page or XML transaction is *not* the same thing.

However, a standard header which points to a URI for posting client
observations -- where the standard is clearly for short, automatically
generated messages of a certain kind -- would do.

But then you have the problem of people spamming the error reporting
mechanism :(

> protocol. Is my interpretation accurate?

I think so :)

However at least the letter is addressed to the house of whoever send
the broken response.  And it should include the URI and method.

It it's a shared house, they might still find it useful.  If they have
a complicated house, and they're getting letters like this which they
can't decipher, they could consider using better URI distinction.

But, frankly, if they _want_ to receive these messages, they could
advertise that in responses with a "Auto-Feedback" header (see below).

> (and things break when they implicitly do).  Or are you talking
> about other bug-reporting methods? If it is the latter, than what
> you seem to be saying is that your method is at least as bad as
> others as far as bug origin identification is concerned. I would
> agree with that!

I agree!

Reporting bugs by a different path is better in fact.  The client can
potentially report all the headers of the transaction, efficiently
(i.e. it doesn't have to be after each transaction - multiple errors
could be aggregated), as well as text about the problem and a URI
pointing to more detail for the server's human admins.

If servers who are interested in such observations by clients, say as
much using a header "Auto-Feedback: /auto-bugs.pl", then the servers
can totally control where feedback is sent according to who is the
source of the response.

In that way, the feedback can be properly addressed.

Reporting them immediately is just a convenient way of getting it
done, out of the way, and into the same log file.  But if server
admins _want_ that, they can splice messages received by a different
path directly into the logs.  I doubt if they'd want to, but they could.

> themselves to avoid being broken.

I disagree with your depth of cynicism.  Logging errors does sometimes
lead to them being fixed.  It doesn't guarantee it, but makes it more
likely.

Also, no matter how intelligent an implementation, it's self testing
will never be as thorough as the testing done by all the clients using
it.  It's a simple question of resources and diversity -- and the fact
that the specifications are very complicated, inexact, ever-changing,
and usually a bit broken themselves.

-- Jamie

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 23 Jun 2004 12:09:55 -0600 (MDT)

On Wed, 23 Jun 2004, Henry Story wrote:

> Since every consumer of XML is faced with the ietf and w3c standards
> that state that one should *not* consume badly formed responses,
> everyone is going to need to be able to report errors if we don't
> want market pressures to lead us down the path of incompatible and
> broken implementations as html did.

Can you explain the logic here? How can a "protocol to auto-report
errors" reduce market pressures on XML consumers to be tolerant to
malformed XML?

> The problem with having to find a specific error service uri, is
> that this requires one or more extra requests to other uri, many of
> which may themselves be broken.

Are you trying to optimize the number of messages on the wire?  Or are
you saying that an "error service at error service uri" is more likely
to be broken than the implementation that handles ERR request? These
are very different optimization goals!

> The advantage of ERR is that I don't need to know about any other
> URI to be able to notify it of the problem. I have already
> communicated with it, so I just need to notify it of the ERR.

The problem is that HTTP does not have a useful notion of "already
communicated with it". "It" can be rather complex and may partially or
fully change from one request to another.

Another ERR disadvantage is that it requires content-serving agents to
handle error reports instead of assigning error-report handling to
error-handling-agents. Things that serve content may not be the best
things for fixing that content (for numerous reasons).

> There is currently a fundamental asymmetry in error reporting
> between the client and the server.

Depends on your point of view, I guess. Clients report errors to
client "owners/users". Servers report errors to server "owners". This
part is very symmetric. While it is true that servers also report some
errors to clients, that is a simply a side-effect of the fundamental
request/response transaction interface: the server has to respond. The
error response that the server sends is not intended to auto-fix the
client.

There is also a fundamental assumption of transaction atomicity,
making one transaction independent from another (except for caching,
which is a low-level performance optimization hack that is supposed to
be transparent to higher-level agents).

> Every request allows the server to report an error, but none allow
> the client to report an error back to the server. This is one reason
> this seemed like this proposal might help restore the imbalance.

You may be trying to change a side-effect of fundamental principles
(see above). That may not be possible without changing those
principles first.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 23 Jun 2004 12:20:58 -0600 (MDT)

...
> and humans will see it and can figure out what it means.

If the bug-reporting protocol is designed to target humans, it should
be optimized/tailored for human consumption. Henry's original premise
was that the ERR protocol is designed to help future machines to fix
themselves.

Alex.

---

From: Justin Chapweske <[email-masked]>
Date: Wed, 23 Jun 2004 13:21:00 -0500

I think the spamming problem can be largely mitigated with two
techniques:

o Define the error reporting as a best effort service that may silently
drop reported errors.

o Use highly aggressive throttling of multiple errors reported by the
same IP address, or even by classes of user-agents.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 23 Jun 2004 12:24:01 -0600 (MDT)

On Wed, 23 Jun 2004, Joris Dobbelsteen wrote:

> The responsibility of the content might be with a different person
> than the responsibility to keep the server alive.

Same for access rights to the content. The more details ERR request
contains, the higher are the chances that wrong people will get too
much information about content they should not have access to.

Alex.

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 23 Jun 2004 14:25:57 -0400

> was that the ERR protocol is designed to help future machines to fix

When we can demonstrate running code that can take advantage of this,
then it's time to determine what the requirements are for a protocol
extension to enable it, not the other way around.

-- 
Scott Lawrence

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 23 Jun 2004 19:31:42 +0100

> already communicated with it, so I just need to notify it of the ERR.

Eh?

What's the difference between:

   1. Having to POST /report-errors.pl HTTP/1.1 etc. etc. with report.

   2. Having to ERR /index.xml HTTP/1.1 etc. etc. with report.

?

The only difference I can see is that the former is more useful to the
server people, because they can cause reports to go to the responsible
person(s) for the exact response which has an error.

Example:
========

The exact server which is relevant to a particular response may depend
on factors which only the server people know.

This is why a server _must_ be what is responsible for providing that
error reporting mechanism.  Hence a bug-reporting URI header.

You may have 100 back-end servers all behind a load balancer, but only
1 of them is sending "Content-Type: text/xml" due to misconfiguration.
All the others are sending "Content-Type: text/xml; charset=utf-8".

This is a crucial point.  If you don't see this, you won't see why
sending an ERR immediately after the buggy reponse isn't helpful:

   *Every single request to the world-visible load balancer is proxied
   to a different back-end server at random*.

In that case, it's useless to send an ERR immediately after getting
"Content-Type: text/xml", because the ERR will be forwarded to the
_wrong_ server 99 times out of 100.

Whereas, if the back-end servers are able to specific a bug URI, then
errors can be forwarded to the _correct_ server always.

How?  Each back-end server provides an appropriate header, like this:

   Bug-URI: /bug-logger.pl?server=box54

Then the server people see the report, and they are all referring to
box54, and they know what to fix straight away.  (Paranoid servers who
don't want to reveal their topology use an opaque cookie instead)

As a client, you cannot possible know the topology, or know who is
responsible for each response you receive.  The server administrators,
however, can configure their systems like that _if_ they want to
collect that data.

That is infinitely more useful, to the server people, than an ERR
response which has no association whatsoever with any part of the
server farm.

> This is one reason this seemed like this proposal might help restore 

You may be right about the principle of reporting.  But your method of
sending ERR is flawed, primarily because it's totally unrelated to the
request it's reporting on.

Remember, even if a client think's it is using a single TCP
connection, by the time it reaches the servers that is no longer true.

Every request is split up independently, and retains no association.

So the servers have no idea which response your report applies to.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 23 Jun 2004 19:34:12 +0100

> servers point a single error reporting server.

It's probably obvious, but fwiw I agree.  An error reporting URI, plus
a standard indicating _what_ should be reported and how.

Alex's point about revealing data if the report is too detailed is
also important.

-- Jamie

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 23 Jun 2004 12:41:12 -0600 (MDT)

On Wed, 23 Jun 2004, Jamie Lokier wrote:

> will never be as thorough as the testing done by all the clients
> using it.

That's not the point. The point is that if an implementation can
self-fix problem X, then that implementation can usually test for X.
If an implementation cannot self-fix problem X, it is pointless to
inform that implementation (rather than a human) that X is a problem.

Alex.

---

From: Jamie Lokier <[email-masked]>
Date: Wed, 23 Jun 2004 19:56:28 +0100

> inform that implementation (rather than a human) that X is a problem.

Ok, now I understand your point.

I agree, at least for the next decade or two.

(Specifications are imprecise and broken too, so there comes a point
when the question of whether to self-fix X, having identified a
logical deviation from specification through self-analysis, is
dependent on a value judgement about the specification, for which
feedback from communicating peers is useful.)

-- Jamie

---

From: Henry Story <[email-masked]>
Date: Thu, 24 Jun 2004 16:16:40 +0200

In order to avoid an avalanche of emails generated by responding point 
by point to each of the thoughtful answers, I would like to see if I 
can summarize the main points.

1. There is consensus that automated error notification systems are 
needed.

They are needed because the specs now require broken content to be 
discarded but market pressures will requires them to nevertheless be 
interpreted. In a war between standards and market pressures, market 
pressures win. Automated error reporting _in_a_form_to_be_determined_ 
will create a feedback loop allowing a wider number of actors to help 
cooperate in the application of the standards.

2. The question of who/what should be notified of an error.

This is a secondary question.

Here I have a number of contradictory intuitions.
    - If an object in the day to day world breaks, say a tire, I don't 
notify it that it is broken, but the manufacturer. Perhaps the tire has 
a "Service-Error: xxx"  phone number printed on it that I can use to 
send a problem report to the manufacturer
    - If I am talking to someone and they are stepping on my toe, I 
might say "err, you are stepping on my toe". I may nevertheless 
continue to listen to what they are saying.
    - If I send a government agency a request for a form, and they send 
me something back in spanish (which I don't speak, but can decipher due 
to the similarity between Spanish and French, which I do know), I may 
send back another letter to the same address explaining the error in a 
language well understood by everybody to be an error message. And if 
this is not the case in your country, would you not be pleased if it 
were the case? Perhaps one could all agree that letters sent in a RED 
envelope are error messages to the agency to which it is addressed. It 
would then be a matter of the institution of which the agency is a part 
to define a policy of what to do with red letters. They may allow them 
to go to the agency itself. They may sample some of them to see if the 
agency is adapting its behavior correctly. They may send them to some 
completely different address that specializes in dealing with those 
messages.

For me as a consumer the red letter method is much easier to work with. 
I know that the first letter reached the agency (whether the address is 
a PO box that gets forwarded to someone else or whatever is none of my 
concern). So out of all the things I know from that institution to be 
alive, that one is the one I have the most direct evidence for being so 
- I am holding the evidence in my hand! Notice that I do not care that 
my letter reaches the exact same person (server, apache instance, 
thread, processor) who dealt with my previous request. I am speaking to 
the agency resource, and as far as I am concerned that is all I need to 
know.

The relation between these intuitions and the two proposals are quite 
clear.
  - PacerErrVerb: http://www.intertwingly.net/wiki/pie/PaceErrVerb
  - PaceServiceError: 
http://www.intertwingly.net/wiki/pie/PaceServiceError

Henry Story

PS. For the Europeans among you who know about Asterix and Obelix, 
there is a cartoon called "Les 12 Traveaux d'Asterix", where the two 
heroes are given the task to get an answer for a simple question from a 
building. Simple enough they think. The problem is that the building 
turns out to be inhabited by a sprawling bureaucracy where each office 
they turn to, an unpleasant person just redirects their call to some 
other floor and other office.

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 24 Jun 2004 10:30:00 -0400

> 1. There is consensus that automated error notification systems are 

I hear no such consensus.  I certainly am not a part of any such.

-- 
Scott Lawrence
Consulting Engineer
Pingtel Corp.   
sip:[email-masked]
+1.781.938.5306 x162

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 24 Jun 2004 09:04:33 -0600 (MDT)

> I hear no such consensus.  I certainly am not a part of any such.

Ditto. You may face fewer objections if you formulate #1 as

	"some automated error notification systems might be useful in
	some contexts".

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 24 Jun 2004 09:26:02 -0600 (MDT)

On Thu, 24 Jun 2004, Henry Story wrote:

> notify it that it is broken, but the manufacturer.

Yes, or a car technician, or your significant other. You will talk to
whoever you think is responsible for _fixing_ the tire (if broken tire
is the primary problem and your goal is to fix it). If collecting
money from the manufacturer is your goal, in some countries, you might
talk to a lawyer first. If informing other drivers of a bad tire brand
is your goal, you will contact some customers union.

> might say "err, you are stepping on my toe".

Yes, and you are not saying that to someone's leg or even someone's
torso. You will talk to whoever you think is ultimately responsible
for freeing your toe from the pressure (which, in some corner cases,
may not be the owner of the leg that is on your toe!).

>     - If I send a government agency a request for a form, and they
> send me something back in spanish ... I may send back another letter
> to the same address explaining the error in a language well
> understood by everybody to be an error message.

You might, but this is a fuzzy example that depends on whether agency
is using the same address for all correspondence, whether agency
departments are efficient at forwarding your letter internally,
whether Spanish department has English speakers, whether you want a
speedy response, etc.

Note that if you are more interested in solving the general problem
(which is wrong language used for communication to customers) than in
getting the right form, then you probably should complain to customer
service rather than the department that sent you the form (and, yes,
customer service address may be the same as the department address).

So, in all these examples, you are most likely to contact the entity
responsible for troubleshooting. That entity depends on the actual
problem you want to solve and it may or may not be the same entity
that caused the trouble.

Alex.

---

From: Henry Story <[email-masked]>
Date: Thu, 24 Jun 2004 20:50:26 +0200

Can I turn this round and ask the group how we can deal with the 
following problem?

The Atom group is writing a spec to be used for applications to be 
deployed by the general public. The general public is going to create 
Blog Feeds which are xml and place them on servers. These servers will 
very often have mime types set incorrectly, so that for example xml may 
be served as text/xml even though their encoding is not ascii. Even if 
the feed were served in ascii it seems that text/xml should only allow 
an application to read the data not to process it. Anyway there are a 
huge number of ways things can go wrong in subtle ways. Not only that 
but have found empirically that over 40% of current feeds in the real 
world are already broken.

The xml/http specs combined insist on the importance of refusing to 
parse xml content that is malformed. This I believe is a very important 
requirement. No one wants to go down the complex and tortuous road html 
went down. Indeed that is why xml makes such a strong case for not 
processing malformed content.

We have a specs that insist that one should not do certain things. Yet 
we know that the reality of the world will force feed readers to parse 
such broken xml.

	1- should we not use xml?
	2- should we specifically ignore some RFC as proposed in [1]	3- should 
we make specs that stick to the letter of other RFCs, but are 
impossible to follow?
	4- should we all work together to slightly alter the http and xml 
specs so that breaking the rules are allowed by clients if certain 
appropriate error reporting strategies are attempted?

	Sincerely,

		Henry Story

[1] http://intertwingly.net/wiki/pie/PaceShouldBeWellFormed

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 24 Jun 2004 13:54:13 -0600 (MDT)

Disclaimer: I am not a MIME/XML expert.

The problem you seem to be describing is incorrect mapping among
the following three pieces of [mis]information:

	- filename extension
	  (.xml)

which some origin servers [incorrectly] map to:

	- HTTP MIME type/charset
	  (text/xml; implied ascii)

which may not represent:

	- feed MIME type/charset
	  (application/atom+xml(?); possibly not ascii)

Atom WG cannot solve the problem in the middle of the above chain. You
can recommend that atom+xml resources do not use .xml extension if
possible; you may recommend .atom extension where applicable. This
recommendation is likely to be ignored if existing content producers
(and their tools) or consumers (and their tools) prefer .xml
extensions for obvious reasons unrelated to Atom (it is an XML
document, after all).

Other that that, declare the problem out of Atom WG scope. Ignore it.
Work on a general solution outside of the Atom WG, if you think there
is a general solution that will prevent MIME mismatch better than RFC
3023 does. In this context, #4 on your list is not a cure, IMHO. It's
a misapplied bandaid.

HTH,

Alex.

On Thu, 24 Jun 2004, Henry Story wrote:

> 	2- should we specifically ignore some RFC as proposed in [1]
>	3- should we make specs that stick to the letter of other
>          RFCs, but are impossible to follow?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 24 Jun 2004 22:25:30 +0200

> was that the ERR protocol is designed to help future machines to fix

I think the automatic machine-fixable scenario was more a bonus to this  
proposal, not the premise. Henry needs to correct me if I'm wrong, but the  
proposal is mainly about having some standardized way to notify to a  
server that a given resource is broken. The obvious way to notify that a  
resource is broken, was for both me and Henry to ERR the actual broken  
resource.

But, you've made some points during the last posts that the entity behind  
the URI being ERRed may not be the same as the entity that served the  
broken resource in the first place. However, I'm not convinced how  
applicable this scenario is for Atom. Atom will mostly be served from  
personal weblogs, in very low-scale hosting environments. The chance of  
requesting the same resource from the same entity twice in a row is, in  
the case of Atom feeds, probably more than 95%. So first doing GET on a  
URI, and then ERR the same URI, will more than most likely send the  
request to the exact same entity twice.

But as this proposal is trying to cover more than just Atom use cases, all  
use cases must be taken into account. Your comments have been proven very  
valuable in my thoughts around this, Alex. Thanks.

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