Hi Chris,

I'll be honest, I am starting to find this project very
overwhelming on an intellectual level.
I don't know how long I can keep up.

My alarm bells go off. You have a veto. If you think it is like this, the drawbacks may outweigh the benefits or something is awry and it shouldn't be done this way. Possibly it could be alleviated if we base our changes off of top-down tests like Acid3. Thank you for the link to acid3. Maybe I am adding unnecessary complication.

And the security implications of AJAX scare the crap out of me.
We're making web requests at the behest of code sent to us by total

I think there is a restriction, which may be a convention rather than something that is enforced by code, that AJAX cannot load from outside domains, but only from the domain of the original page. I think you're right that another entry point from the internet is worrisome. It is one more place where we talk to the curl library and something like malware could be retrieved. Although, is this different than the security implications of the web request browsed with the 'b' command in the first place?

How do we know when we have done it securely?

And what are the implications of doing that XHR stuff in startwindow.js,
rather than native C?  If you need it ported from JS to C, I can
certainly do that, as I have enough familiarity with both languages.

Thank you. It is a mixture of both right now. The reason that there is a javascript piece is that there was an existing JS implementation that I was able to modify. This came from the Env JS project. The JS piece mostly gathers parameters. Then it calls the native code, fetchHTTP:

var entire_http_response = document.fetchHTTP(this.url,this.method,headerstring,data);

Kevin
_______________________________________________
Edbrowse-dev mailing list
[email protected]
http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev

Reply via email to