Re: ERR header (NEW ISSUE: Drop Content-Location)

Very good points below. I have developed the idea following your  
final suggestion. Here is an improved sketch of how this could work.

---------8<---------------------------------
ERR /page0 HTTP
Sender: W3C
Signature: W3C signature
Conten-Type: application/rdf+n3
Cache-Control: XXX?

@prefix : <http://w3c.org/err> .
@...

<http://err.w3c.org/bug123231> a err:bugReport;
    err:initialRequest [ :method "GET";
                         :resource <http://eg.org/page0>;
                         :header "Accept: text/html"; ];
    err:response [ :header ...;
                   :body "<xml>...</xml>";
                 ];
    err:comment "the response...";
    err:relevantSpec <http://...>;
    err:relevantDiscussion <...> .
---------8<---------------------------------

So here I am thinking that the ERR method would not be implemented by  
any clients, but by specialized ERR reporting agents, owned perhaps  
by the W3C, google or other responsible bodies, that can afford a  
signature to identify themselves.

It is true that a request does not necessarily always travel the same  
route, through the same proxies. But similar bug reports will more  
often go through the same proxies than not. Perhaps one also needs a  
way to ask for proxy traversal information on a request, so that one  
can trace where the error is located?


On 29 Nov 2006, at 15:15, Joris Dobbelsteen wrote:
>> -----Original Message-----
>> From: ietf-http-wg-request@w3.org
>> [mailto:ietf-http-wg-request@w3.org] On Behalf Of Henry Story
>> Sent: woensdag 29 november 2006 23:19
>> To: Henrik Nordstrom
>> Cc: Roy T. Fielding; Anne van Kesteren; HTTP Working Group
>> Subject: Re: NEW ISSUE: Drop Content-Location
>>
> [snip]
>>
>> Could that be solved my creating a ERR method, so that clients
>> could send feedback to servers at the resource they found wanting?
>>
>> ------------------
>> ERR /page0 HTTP...
>> ...
>>
>> Your Content-Location is broken see spec xyz
>> ------------------
>>
>
> This feature was discussed before.
> See <http://lists.w3.org/Archives/Public/ietf-http-wg/2004AprJun/>.
> Also see <http://www.imc.org/atom-syntax/mail-archive/ 
> msg05546.html> for
> somewhere in a discussion.
>
> I personally think this is a bad idea.
>
> The most important reaon for this is that the ERR reporter *must* be
> guarenteed to have correctly implemented the specifications. Thus it
> should not contain bugs and certainly not generate incorrect reports.
> I'm also wondering how future revisions of the spec might affect  
> current
> deployments that would have such a feature.
> Unless this issue can be solved it seems an inappropriate feature.

ok. So my idea is that clients who use it should identify themselves  
with a signature. Then intermediaries can listen to those ERR  
requests from agents they trust.

>
> Other reasons against it are:
>
> (1) The issue is put by the administrator of the system, rather  
> than the
> developers of the proxy. It generates extra bandwidth and  
> administrative
> overhead for owners of web servers (massive error requests).

Ok. So perhaps it is not a good idea to place this into generalised  
clients, since they may be out of date. If one did the feature should  
never be automated (it should require human intervention)

> (2) How would you blame an specification violating system in-between,
> such as a proxy server?

Could one do this with a header on a request to trace the proxies  
through which the request went?
Perhaps also a header on the ERR call to specify that it is likely an  
intermediary problem. It may be of interest to the resource holder,  
that intermediate proxies are breaking access to his resource...

> (3) It increases server load without any likelyness of solving the
> problem anytime soon. That would be up to the implementor and their
> priorities.


Only if everyone implements it badly. And that would be easy to  
ignore. I can't imagine it getting ever as bad as SPAM email: there  
would be no economic motivation to do this.

> (4) It does not prevent specification ambiguities. This leads to dirty
> implementation hacks in the hope the spec would follow or at least
> reduce errors. The spec has a very slow release cycle, it takes at  
> least
> several months before the spec is updated.

Good point. So the body should point to the relevant specs.

> Of course there are good reasons to support it:
>
> (A) It creates more momentum to keep non-conforming servers up to  
> their,
> hopefully better, latest versions and specification conformance.
>
> My suggestion:
> An official test suite.
> Ideally it would be possible to extract the rules immediately from the
> specs. Maybe the specification should use symantics that could be
> automatically proven ;)
>
> This is just my opinion...
>
> - Joris

Received on Saturday, 2 December 2006 18:29:36 UTC