[Edbrowse-dev] XMLHttpRequest

[Edbrowse-dev] XMLHttpRequest

[Karl Dahlke]

Since almost the dawn of html, <frame> and <iframe> can cause a browser
to fetch other html, perhaps from another domain, and paste the result into the web page.
In this regard edbrowse is more manual than any other browser; you have to click on a link to fetch in the frame.
Not saying I like it that way, I don't, it was just easier at the time.
Anyways other browsers just do it, without worrying about security,
I don't think XMLHttpRequest is any different; except js is directing the http fetch,
and perhaps using the result in some computational way,
rather than html directing the fetch and browsing the result.
Most of the time even js just slaps the html into a <div> where it is browsed;
just a damn fancy complicated, and dynamic, form of iframe.
I'd be surprised if a js fetch had to draw from the same domain, but it might, IDK.
Maybe write some test code and run it on other browsers.

By the way, we should think about expanding all these frames and iframes, as other browsers do,
but it's more work than first appears.
The top half of your "buffer" is this tree from this html on this domain running this instance of js,
and the bottom half of your buffer is that tree from that html on that domain running that instance of js,
so multiple js windows tied to one edbrowse window, which we can't do now, etc etc.
definitely some work there; for now an improved dom and jquery is more important.

Karl Dahlke

Re: [Edbrowse-dev] XMLHttpRequest

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 2731 bytes --]

On Tue, Dec 27, 2016 at 11:12:51AM -0500, Karl Dahlke wrote:
> Since almost the dawn of html, <frame> and <iframe> can cause a browser
> to fetch other html, perhaps from another domain, and paste the result into the web page.
> In this regard edbrowse is more manual than any other browser; you have to click on a link to fetch in the frame.
> Not saying I like it that way, I don't, it was just easier at the time.
> Anyways other browsers just do it, without worrying about security,
> I don't think XMLHttpRequest is any different; except js is directing the http fetch,
> and perhaps using the result in some computational way,
> rather than html directing the fetch and browsing the result.

Actually that's not quite correct.  What browsers usually do is use something
called CORS (cross origin resource sharing) to decide whether a particular
request is ok.

The implementation is a bit complicated but it's basically based on http headers
telling browsers whether access to a resource is allowed.  Specifically this
applies when a request is cross-domain or cross-protocol i.e. from
edbrowse.org to eklhad.net or https to http.

This is important to prevent cross-site scripting attacks and there are a
bunch of systems which implement this.  I don't have the relevant links to hand
but there's lots of documentation on the internet about various browsers'
implementations.  I think there's some kind of standard also.

> Most of the time even js just slaps the html into a <div> where it is browsed;
> just a damn fancy complicated, and dynamic, form of iframe.
> I'd be surprised if a js fetch had to draw from the same domain, but it might, IDK.
> Maybe write some test code and run it on other browsers.

It's actually quite a mixed picture as far as that's concerned.  There're a lot
of AJAX requests cross-domain (using preflite OPTION method requests to set up
CORS stuff) but there're also a bunch of systems I'm aware of using same-origin
AJAX requests for server-generated dynamic content.

> By the way, we should think about expanding all these frames and iframes, as other browsers do,
> but it's more work than first appears.
> The top half of your "buffer" is this tree from this html on this domain running this instance of js,
> and the bottom half of your buffer is that tree from that html on that domain running that instance of js,
> so multiple js windows tied to one edbrowse window, which we can't do now, etc etc.
> definitely some work there; for now an improved dom and jquery is more important.

Agreed.  Though it'd be good, if we ever do this, to mark the frames somehow.  I
*think* js may have access to these frames somehow but I'm not sure what the DOM
looks like for this.

Cheers,
Adam.

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]