On Tue, Dec 27, 2016 at 11:12:51AM -0500, Karl Dahlke wrote: > Since almost the dawn of html, and 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 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.