W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2005

[whatwg] ContextAgnosticXmlHttpRequest: an informal RFC

From: Chris Holland <frenchy@gmail.com>
Date: Wed, 9 Mar 2005 08:42:25 -0800
Message-ID: <8da6ad500503090842790550fc@mail.gmail.com>
On Wed, 9 Mar 2005 12:14:52 +0000, Jim Ley <jim.ley at gmail.com> wrote:
> On Wed, 9 Mar 2005 01:31:50 -0800, Chris Holland <frenchy at gmail.com> wrote:
> > On Wed, 9 Mar 2005 08:57:12 +0000, Jim Ley <jim.ley at gmail.com> wrote:
> >If the User Agent is a traditional web
> > browser, the only way a given document could ever initiate a request
> > to a host different from the one that served it, would be through a
> > ContextAgnosticHttpRequest (i'm liking this name less and less, sorry
> > about that), and this request would infallibly send, in every request,
> > the full URI of the document initiating the request, as the value of
> > the "Referer" header.
> 
> Are you sure you're not advocating this to get around privacy based
> proxies of the type that normally disable such referrer based content
> so as to reliably block
> privacy invasions?
> 

well, if a proxy starts filtering out http headers sent by the client,
there isn't much we can do about that now is there. heh.

> > > Please don't have any solution that limits the user to XML, it's a
> > > pointless arbritrary restriction that offers nothing but serious
> > > performance hits to the client, and complications to the user.
> >
> > well it would appear XML validity already is a restriction, but okee.
> 
> Nope, there's no such restriction, and very few of the implementations
> that I know of that use xmlhttprequest on websites use XML.
> 

... ok ... google maps does. a9 does. ask jeeves does. but ok, fair
enough, many other developers just may not. anyway, i should have left
this issue to another debate in the first place, it shouldn't really
affect design for this feature.

thanks for the feedback! :)

-chris



-- 
Chris Holland
http://chrisholland.blogspot.com/
Received on Wednesday, 9 March 2005 08:42:25 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:39 UTC