RE: Exceptions thrown by the mobileok checker

Hi Sean,

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

Yes, basically so far we are taking into account most of them, but yesterday
we discovered that in XHTMLHTTPResource invalid URIS are discarded. In order to have a homogeneous treatment, we should not discard this URIS until we try to make the request (HTTPResource class) and in that case create a mock HTTPRedirect with the error code.
We should think a solution that fits in our design with low impact.
Any thoughts on this?


>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.

Ooops, it seems like we forgot to finish the management of HTTPS warnings.
We will fixe it asap.


-----Mensaje original-----
De: Sean Owen [mailto:srowen@google.com] 
Enviado el: miércoles, 30 de enero de 2008 23:08
Para: Abel Rionda
CC: Jo Rabin; fd@w3.org; public-mobileok-checker@w3.org
Asunto: Re: Exceptions thrown by the mobileok checker

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
problems.

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.

Sean

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 Thursday, 31 January 2008 16:58:37 UTC