W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > January 2008

Re: Exceptions thrown by the mobileok checker

From: Sean Owen <srowen@google.com>
Date: Wed, 30 Jan 2008 17:08:01 -0500
Message-ID: <e920a71c0801301408y53ce7611w3c52f09aaad6bf3@mail.gmail.com>
To: "Abel Rionda" <abel.rionda@fundacionctic.org>
Cc: "Jo Rabin" <jrabin@mtld.mobi>, fd@w3.org, public-mobileok-checker@w3.org

Yeah I'd like to solve this correctly.

I made some changes to at least wrap up random API exceptions that are
thrown in these situations (URISyntaxException, IllegalStateException)
in a TestException.

What needs to happen, additionally? sounds like we are OK with
throwing an Exception if the main document under test has these

But if a linked resource does, there is something we need to do to
create a dummy HTTPResource?

On a related note, the field httpsOutcome in HTTPResource is not used
(written but not read); I wonder if there is some related issue there.


On Jan 30, 2008 10:42 AM, Abel Rionda <abel.rionda@fundacionctic.org> wrote:
> 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.
Received on Wednesday, 30 January 2008 22:08:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:20 UTC