Re: XMLHttpRequest: URI argument for the open() method

On 10/14/06, Anne van Kesteren <annevk@opera.com> wrote:
> On Sat, 14 Oct 2006 19:04:18 +0200, Brad Fults <bfults@gmail.com> wrote:
> > So you just decided not to mention conformance requirements for the
> > URL at all?
>
> Did you actually read the relevant section?
>

Indeed I did read the section; twice in fact. I apologize if I'm
missing the key phrase, but here are the pieces of text that I see
dealing with the url parameter (emphases mine):

> open(method, *url*, async, user, password), method
>

> Calling this method must initialize the object by remembering the method, *url*, async
> (defaulting to true if omitted), user  (defaulting to null if omitted), and password
> (defaulting to null if omitted) arguments
>

> When *url* is a relative reference, it must be resolved using XMLHttpRequest base resource
> identifier reference. If that's not defined, or there's a failure in resolving user agents must
> throw a SYNTAX_ERR. When a non same-origin url argument is given user agents should
> throw a SECURITY_ERR exception.

I fail to see where the conformance requirements for the url parameter
are specified anywhere within the above quoted text. The specification
reader has nothing more to interpret the url parameter value than its
name. Nowhere is it mentioned what type of data should be passed
(beyond the fact that it is a string).

Not to be absurd, but as the referenced draft [1] currently stands, an
implementor could allow only RFC 2616 URL strings specified in reverse
order (e.g. "/moc.elgoog.www//:ptth") and it would be completely
conformant to the XMLHttpRequest specification. This seems
undesirable.

> > But nowhere is it made explicit (as far as I could see) which schemes
> > are actually covered in the specification.
>
> Right, as this is mostly up to implementations for this version.
>

Under this assumption, an implementor could implement XMLHttpRequest
functionality only for the webcal:// scheme (not HTTP or HTTPS) and it
would be considered conformant. This also seems undesirable.

Also, it seems vacuous to specify allowed operations and expected
behavior for an object if no URL scheme at all is specified as
necessary; much like specifying the conformance criteria for a vehicle
in great detail without mentioning whether it will be used on land or
sea.

It would seem to me that  support for the HTTP and HTTPS URL schemes
should be required, leaving room for other schemes as optional.

[1] - http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8#dfn-open

Thanks.

-- 
Brad Fults

Received on Saturday, 14 October 2006 17:48:11 UTC