Re: [foaf-protocols] non issue comments on webid IX draft

Good input for ISSUE-9: Develop WebID Test Suite

On 22 Feb 2011, at 08:36, peter williams wrote:

> Consider adding a test case (or 2) then.
>  
> Large number of false URIs test: If the max len cert message in a record layer is 32k (and we need to check that), we can have a cert with largish n-1 distinct tiny URIs to a null document, and 1 URI with a viable document. A correct implementation WILL use the viable document. An incorrect implementation will not.

As the spec is written now we would not distinguish correct and incorrect. The first server we can call patient and customer friendly, the second server impatient. The first will get be able to help people whose prime web server has gone down, the second will not.
But that is good, we could set up tests to decide how friendly implementations are. There may be a point where friendiness turns into stupidity, though I think that will depend on the use cases.

This is a bit like the question of what a browser should do if someone sends an infinitely large html page. Well most browsers will have some protection in place for that, that depends in part on the memory available.

> Mixed number of true/false URIs test: If the max len cert message in a record layer is 32k (and we need to check that), we can have a cert with largish n-1 distinct tiny URIs to a huge document with no cert declarations, and 1 URI with a viable document delivered with HTTP no-cache header. A correct implementation will process the huge document n-1 times. An incorrect implementation will not.

I suppose you mean that both are sent with HTTP no-cache headers. Yes, that would force the fetching of the page. An intelligent server though could see that these pages all redirect to the same place, and so change the order to parse the one that was different first.

But tests on caches will  be useful.

>  
> Redirect test: If the max len cert message in a record layer is 32k (and we need to check that), we can have a cert with largish ordered set of n distinct tiny URIs n-1 of which redirect to the next tiny URI in the order, and 1 which is the last URI in the order that points to a viable document. A correct implementation of the verification agent will redirect n-1 times and process the viable document. An incorrect implementation will not.

We have defined no order on how the WebID should be looked at. 

But redirection should be something we should test for, and either document in the spec, or in a related spec.

Henry

>  
>  

Social Web Architect
http://bblfish.net/