RE: Exceptions thrown by the mobileok checker

Hi folks,

We think that the issue of invalid URIS should be managed in a different way:

*In case of the main document: As Francois said, so far we are not taken into account all invalid possible inputs to the checker (not only the URI). These cases should be encapsulated into our own exceptions (Perhaps having more than one exception should be useful). 
In case of having an HTTP_RESSPONSE-1 error on main documents, it does not make sense passing tests and we should raise an exception. Currently we are taking this approach only for DNS errors on main document: 

Exception in thread "main" org.w3c.mwi.mobileok.basic.TestException: A network error has happened while retrieving the requested Web page.
MobileOK Basic Test can not be launched.

*In other case (resources): In the related test we include the suitable HTTP_RESPONSE-* message. Coming back to Francois message:

> In other words:
> <a href="thisdomaindoesntexist.com">http://thisdomaindoesntexist.com</a>
> -> is treated correctly and return a FAIL message.
> whereas:
> <a href="http://">http://</a>
> <a href="invalid://something">invalid://something</a>
> -> are not treated at all...

The first case ("http://") is a bug and it should be treated as an HTTP_RESPONSE-* error.
But in case of having an invalid protocol, we think that is right not report
about it (Not a HTTP_RESPONSE-* error) because as the mobileOK document states:

"As noted under 2.4.6 Included Resources and 2.4.7 Linked Resources the URIs that are relevant to mobileOK are those that, when represented in an absolute form, have either the http or the https scheme. Requests should not be made for URIs with schemes other than http and https."

Regards,

Miguel and Abel.


-----Mensaje original-----
De: public-mobileok-checker-request@w3.org [mailto:public-mobileok-checker-request@w3.org] En nombre de Jo Rabin
Enviado el: miércoles, 30 de enero de 2008 16:00
Para: fd@w3.org
CC: public-mobileok-checker@w3.org
Asunto: RE: Exceptions thrown by the mobileok checker


I guess that these cases are all covered under DNS Resolution Error in the following?

"If an HTTP request does not result in a valid HTTP response (because of network-level error, DNS resolution error, or non-HTTP response), FAIL"

Jo

> -----Original Message-----
> From: Francois Daoust [mailto:fd@w3.org]
> Sent: 30 January 2008 14:54
> To: Jo Rabin
> Cc: public-mobileok-checker@w3.org
> Subject: RE: Exceptions thrown by the mobileok checker
> 
> Handling is better in that case, but invalid links seem to be simply
> ignored by the checker, and that doesn't look right.
> 
> In other words:
> <a href="thisdomaindoesntexist.com">http://thisdomaindoesntexist.com</a>
> -> is treated correctly and return a FAIL message.
> 
> whereas:
> <a href="http://">http://</a>
> <a href="invalid://something">invalid://something</a>
> -> are not treated at all...
> 
> I guess this links back to bug 5358: No errors on HTTP errors. Abel?
> 
> François.
> 
> 
> On Wed, 2008-01-30 at 14:24 +0000, Jo Rabin wrote:
> > Presumably the same exceptions get thrown if a page under test has an
> > invalid reference to some external resource? In which case I suggest
> > that we catch these exceptions before beta starts on the basis that the
> > result should be FAIL.
> >
> > Jo
> >
> >
> >
> > > -----Original Message-----
> > > From: public-mobileok-checker-request@w3.org [mailto:public-mobileok-
> > > checker-request@w3.org] On Behalf Of Francois Daoust
> > > Sent: 30 January 2008 14:13
> > > To: public-mobileok-checker@w3.org
> > > Subject: Exceptions thrown by the mobileok checker
> > >
> > >
> > > Hi,
> > >
> > > While re-writing the mobileOK checker validation page, I encountered a
> > > few cases when the checker throws some exceptions, not because it
> > > crashed, but because the URI entered is either inaccessible or not
> > > valid. See examples below.
> > >
> > > The exceptions being thrown are developer-readable, but throwing such
> > > exceptions when it's not the checker's fault makes it harder to wrap
> > > something around it. If you take a look at:
> > > http://validator.w3.org/mobile/alpha?docAddr=test
> > > ... one would immediately think the checker crashed, and try again,
> > and
> > > again, and then yell by email.
> > > [note the exception returned is slightly different from the example
> > > below because the version of the JAR is older]
> > >
> > > I'll handle the exceptions I can think of in the validator page to
> > > return a more user-friendly message that really states that the
> > problem
> > > lies with the URI, but I tend to think the checker should be a black
> > box
> > > that only throws exceptions when it crashes because of a bug, not
> > > because the URI is incorrect, and thus that the catching should rather
> > > be done within the checker.
> > >
> > > Or that we should at least provide the list of the exceptions that may
> > > be thrown by the checker [does it already exist?]
> > >
> > > I don't think that needs to be done for the beta though...
> > > If there's no objection, I could also action myself and do that,
> > > although I'm not sure I'll be able to work on it very soon.
> > >
> > > What do you think?
> > >
> > > Francois.
> > >
> > >
> > >
> > > Examples:
> > >
> > > 1. network error because the resource cannot be accessed:
> > > java -jar mobileOK-Basic-RI-1.0-deploy.jar thisdomaindoesntexist.com
> > > Exception in thread "main" org.w3c.mwi.mobileok.basic.TestException: A
> > > network error has happened while retrieving the requested Web page.
> > > MobileOK Basic Test can not be launched.
> > >         at
> > >
> > org.w3c.mwi.mobileok.basic.Preprocessor.preprocess(Preprocessor.java:37)
> > >         at
> > >
> > org.w3c.mwi.mobileok.basic.Tester.getPreprocessorResults(Tester.java:91)
> > >         at org.w3c.mwi.mobileok.basic.Tester.main(Tester.java:201)
> > >
> > >
> > > 2. URI syntax error because the URI is invalid:
> > > java -jar mobileOK-Basic-RI-1.0-deploy.jar http://
> > > Exception in thread "main" java.net.URISyntaxException: Expected
> > authority
> > > at index 7: http://
> > >         at java.net.URI$Parser.fail(URI.java:2809)
> > >         at java.net.URI$Parser.failExpecting(URI.java:2815)
> > >         at java.net.URI$Parser.parseHierarchical(URI.java:3063)
> > >         at java.net.URI$Parser.parse(URI.java:3014)
> > >         at java.net.URI.<init>(URI.java:578)
> > >         at org.w3c.mwi.mobileok.basic.Tester.main(Tester.java:136)
> > >
> > >
> > > 3. Protocol error when the URI is valid but the protocol unknown:
> > > java -jar mobileOK-Basic-RI-1.0-deploy.jar invalid://something
> > > Exception in thread "main" java.lang.IllegalStateException:
> > unsupported
> > > protocol: 'invalid'
> > >         at
> > >
> > org.apache.commons.httpclient.protocol.Protocol.lazyRegisterProtocol(Pro
> > to
> > > col.java:149)
> > >         at
> > >
> > org.apache.commons.httpclient.protocol.Protocol.getProtocol(Protocol.jav
> > a:
> > > 117)
> > >         at
> > > org.apache.commons.httpclient.HttpHost.<init>(HttpHost.java:107)
> > >         at
> > >
> > org.apache.commons.httpclient.HttpMethodBase.setURI(HttpMethodBase.java:
> > 28
> > > 0)
> > >         at
> > >
> > org.apache.commons.httpclient.HttpMethodBase.<init>(HttpMethodBase.java:
> > 22
> > > 0)
> > >         at
> > >
> > org.apache.commons.httpclient.methods.GetMethod.<init>(GetMethod.java:89
> > )
> > >         at
> > > org.w3c.mwi.mobileok.basic.HTTPResource.<init>(HTTPResource.java:107)
> > >         at
> > > org.w3c.mwi.mobileok.basic.HTTPResource.<init>(HTTPResource.java:80)
> > >         at
> > >
> > org.w3c.mwi.mobileok.basic.HTTPTextResource.<init>(HTTPTextResource.java
> > :3
> > > 7)
> > >         at
> > >
> > org.w3c.mwi.mobileok.basic.HTTPXHTMLResource.<init>(HTTPXHTMLResource.ja
> > va
> > > :93)
> > >         at
> > >
> > org.w3c.mwi.mobileok.basic.Preprocessor.preprocess(Preprocessor.java:31)
> > >         at
> > >
> > org.w3c.mwi.mobileok.basic.Tester.getPreprocessorResults(Tester.java:91)
> > >         at org.w3c.mwi.mobileok.basic.Tester.main(Tester.java:201)
> > >
> > >
> >
> >

Received on Wednesday, 30 January 2008 15:43:21 UTC