RE: Exceptions thrown by the mobileok checker

Abel makes a good point, I think. (2.2) "mobileOK tests are only meaningful when the URI under test resolves to HTML content delivered over HTTP."

So if the test doesn't even start then that's not a FAIL.

I'm not sure that throwing an exception is the right thing to do in this case, I would expect to see a result document stating that mobileOK was not applicable or something like that? 

I'm thinking that this situation could do with clarification in the spec.

Jo

> -----Original Message-----
> From: Abel Rionda [mailto:abel.rionda@fundacionctic.org]
> Sent: 30 January 2008 15:43
> To: Jo Rabin; fd@w3.org
> Cc: public-mobileok-checker@w3.org
> Subject: 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 16:01:03 UTC