muta...@gmail.com
2021-10-16 08:29:32 UTC
I moved a step closer to an HTML terminal with the below
code. Someone else provided the Javascript so I don't know
how to get rid of the utf8 stuff yet.
One thing that surprised me was that unlike an nntp or telnet
session, http seems to send an HTML page and then it never
gets a response back, ie the read() just sits there. It seems that
the browser is designed to ignore that open connection (neither
end seems to close it) and then it starts a brand new connection.
This means I didn't get the expected "GET /?key=X'.
My desire is for PDOS/386 to effectively open a serial port
connection to a BBS that is emitting HTML code instead of
ANSI escape sequences. As such, I need the "GET /" to go
up via the same line. There's not really a concept of a new
connection.
But because I would like the BBS to be able to operate with
a normal web browser too, I think the BBS needs to be
defined to have either persistent http connections or
non-persistent. ie both forms are valid.
Unless there's a way to get the browser to keep the
connection open?
Note that my htmlterm application running under PDOS/386
won't bother actually interpreting that javascript, it will just
assume that the javascript is soliciting a keystroke and send
a "GET /?key=whatever" up the serial line.
BFN. Paul.
<html>
<body>
line 1<br>
line two<br>
line 3<br>
<script>
async function handle_key_press(e) {
const utf8 = new TextDecoder('utf-8');
const resp = await window.fetch('/?key=' + e.key);
const reader = resp.body.getReader();
const body = document.querySelector('body');
body.innerHTML = '';
while (true) {
const {value, done} = await reader.read();
if (done) break;
body.innerHTML += utf8.decode(value, {stream: true});
}
}
window.onkeypress = handle_key_press;
</script>
</body>
</html>
code. Someone else provided the Javascript so I don't know
how to get rid of the utf8 stuff yet.
One thing that surprised me was that unlike an nntp or telnet
session, http seems to send an HTML page and then it never
gets a response back, ie the read() just sits there. It seems that
the browser is designed to ignore that open connection (neither
end seems to close it) and then it starts a brand new connection.
This means I didn't get the expected "GET /?key=X'.
My desire is for PDOS/386 to effectively open a serial port
connection to a BBS that is emitting HTML code instead of
ANSI escape sequences. As such, I need the "GET /" to go
up via the same line. There's not really a concept of a new
connection.
But because I would like the BBS to be able to operate with
a normal web browser too, I think the BBS needs to be
defined to have either persistent http connections or
non-persistent. ie both forms are valid.
Unless there's a way to get the browser to keep the
connection open?
Note that my htmlterm application running under PDOS/386
won't bother actually interpreting that javascript, it will just
assume that the javascript is soliciting a keystroke and send
a "GET /?key=whatever" up the serial line.
BFN. Paul.
<html>
<body>
line 1<br>
line two<br>
line 3<br>
<script>
async function handle_key_press(e) {
const utf8 = new TextDecoder('utf-8');
const resp = await window.fetch('/?key=' + e.key);
const reader = resp.body.getReader();
const body = document.querySelector('body');
body.innerHTML = '';
while (true) {
const {value, done} = await reader.read();
if (done) break;
body.innerHTML += utf8.decode(value, {stream: true});
}
}
window.onkeypress = handle_key_press;
</script>
</body>
</html>