ibm-netrexx

NetRexx, file paths, and copy file

Classic

List

Threaded

5 messages Options

Jeff Hennick-3

NetRexx, file paths, and copy file

This Message Is From an External Sender

This message came from outside your organization.

This is a general NetRexx question that has come to light in writing a Pipelines stage. First, the problem.

This is in Windows 10, using Firefox as the default web browser.

I have written a stage, DISPLAY, that writes data to a .HTML-file and then uses a system command call to a web browser to display the file by asking the os to open the HTML file. It works fine using the current working directory to store this temporary file. It has been suggested that it would be better to use the system TMP directory for this purpose. OK, I can get its name by using System.getProperty("java.io.tmpdir"). Doing this it also works fine.

But I also want to use an external CSS stylesheet. So I put this line in the HTML file: <link rel="stylesheet" href="'filename'"> . The filename is previously defined as greenbar.css .

If both the HTML file and greenbar.css are in the same directory, i.e. the working or the temporary one, this works.

If I change the filename to a relative path, ./greenbar.css , it works.

The problem is that I would like to have the HTML file in the TmpDir and the CSS file in the working directory (or on a relative path from that). This does not work by any of the ways I can think of.

I have tried using an absolute path of C:/users/jeff/documents/pipe tests/greenbar.css and /users/jeff/documents/pipe tests/greenbar.css . I have even tried putting a copy of greenbar.css in the root directory and using /greenbar.css . None of these have worked.

I have had success with '../../../documents/pipe tests/greenbar.css' , but this requires intimate knowledge of where the TmpDir and the working directory are in the overall tree.

I have come to the conclusion that FireFox refuses to handle absolute paths in this situation, but have not found documentation of this. I have to imagine that other browser and os combinations may also enforce similar rules.

I now come to the workaround of using the TmpDir for both files. This means doing a copyfile of the CSS file from the working directory to the TmpDir. And raises my NetRexx question.

What is the proper, or at least best way, in NetRexx to do a copyfile? Should I use Java's Files.copy() method? This apparently also needs .toPath() on the names.

Anyone helping with copy or the absolute path problem would be most appreciated.

Thank you,

Jeff

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

jlturriff

Re: NetRexx, file paths, and copy file

On 2020-11-25 09:56:08 Jeff Hennick wrote:
> <html>
> <head>

<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=no;">
<style>
/* Mobile */
@media screen and (max-width: 630px){
* {-webkit-text-size-adjust: none}
a[href^="x-apple-data-detectors:"] { color: inherit; text-decoration: none; }
.pfptTitle { font-size:22px !important; line-height:26px !important; text-align: center !important; }
.pfptSubtitle { font-size:14px !important; line-height:18px !important; text-align: center !important; }

.pfptMainWrapper { margin-top: 0 !important; margin-right: 0 !important; margin-left: 0 !important; }
th[class="pfptTableColumnLeft"] {width:100% !important; height:auto !important; display:block !important; text-align: center !important; }
th[class="pfptTableColumnRight"] {width:100% !important; height:auto !important; display:block !important; text-align: center !important; }

.pfptButton { font-size:16px !important; line-height:16px !important; width: 50% !important; display:block !important; margin-right: auto!important; margin-left: auto!important; }
.pfptButton a { font-size: 16px; }
.pfptButton span { font-size: 16px; }
}
/* Tablet, Laptop, Desktop */
@media screen and (min-width: 631px){
th[class="pfptTableColumnLeft"] { width: 50% !important; height:auto !important; }
th[class="pfptTableColumnRight"] { width: 50% !important; height:auto !important; text-align: right !important; }
}
.pfptPreheader { display:none !important; visibility:hidden; mso-hide:all; font-size:1px; line-height:1px; max-height:0px; max-width:0px; opacity:0; overflow:hidden; }
</style>

> 
> <meta name="viewport" content="width=device-width; initial-scale=1.0;
> maximum-scale=1.0; user-scalable=no;"> <style>
> /* Mobile */
> @media screen and (max-width: 630px){
> * {-webkit-text-size-adjust: none}
> a[href^="x-apple-data-detectors:"] { color: inherit;
> text-decoration: none; } .pfptTitle { font-size:22px !important;
> line-height:26px !important; text-align: center !important; } .pfptSubtitle
> { font-size:14px !important; line-height:18px !important; text-align:
> center !important; }
>
> .pfptMainWrapper { margin-top: 0 !important; margin-right: 0
> !important; margin-left: 0 !important; } th[class="pfptTableColumnLeft"]
> {width:100% !important; height:auto !important; display:block !important;
> text-align: center !important; } th[class="pfptTableColumnRight"]
> {width:100% !important; height:auto !important; display:block !important;
> text-align: center !important; }
>
> .pfptButton { font-size:16px !important; line-height:16px
> !important; width: 50% !important; display:block !important; margin-right:
> auto!important; margin-left: auto!important; } .pfptButton a { font-size:
> 16px; }
> .pfptButton span { font-size: 16px; }
> }
> /* Tablet, Laptop, Desktop */
> @media screen and (min-width: 631px){
> th[class="pfptTableColumnLeft"] { width: 50% !important;
> height:auto !important; } th[class="pfptTableColumnRight"] { width: 50%
> !important; height:auto !important; text-align: right !important; } }
> .pfptPreheader { display:none !important; visibility:hidden;
> mso-hide:all; font-size:1px; line-height:1px; max-height:0px;
> max-width:0px; opacity:0; overflow:hidden; } </style>
>
> 
>
>
>
> <meta http-equiv="content-type" content="text/html; charset=UTF-8">
> </head>
> <body>

> 
> 
>
> 
> 
>
> 
>
> 
>
>
> This is a general NetRexx question that has come to light in
> writing a Pipelines stage. First, the problem. 
> 
> This is in Windows 10, using Firefox as the default web browser. 
> 
> I have written a stage, DISPLAY, that writes data to a .HTML-file
> and then uses a system command call to a web browser to display
> the file by asking the os to open the HTML file. It works fine
> using the current working directory to store this temporary file.
> It has been suggested that it would be better to use the system
> TMP directory for this purpose. OK, I can get its name by using
> System.getProperty("java.io.tmpdir"). Doing
> this it also works fine.
> But I also want to use an external CSS stylesheet. So I put this
> line in the HTML file: <link
> rel="stylesheet" href="'filename'"> . The filename is
> previously defined as greenbar.css . 
> 
> If both the HTML file and greenbar.css are in the same directory,
> i.e. the working or the temporary one, this works.
> If I change the filename to a relative path, ./greenbar.css , it
> works.
> The problem is that I would like to have the HTML file in the
> TmpDir and the CSS file in the working directory (or on a relative
> path from that). This does not work by any of the ways I can
> think of.
> I have tried using an absolute path of
> C:/users/jeff/documents/pipe tests/greenbar.css and
> /users/jeff/documents/pipe tests/greenbar.css . I have even tried
> putting a copy of greenbar.css in the root directory and using
> /greenbar.css . None of these have worked.
> I have had success with '../../../documents/pipe
> tests/greenbar.css' , but this requires intimate knowledge of
> where the TmpDir and the working directory are in the overall
> tree. 
> 
> I have come to the conclusion that FireFox refuses to handle
> absolute paths in this situation, but have not found documentation
> of this. I have to imagine that other browser and os combinations
> may also enforce similar rules.
> I now come to the workaround of using the TmpDir for both files.
> This means doing a copyfile of the CSS file from the working
> directory to the TmpDir. And raises my NetRexx question.
> What is the proper, or at least best way, in NetRexx to do a
> copyfile? Should I use Java's face="monospace">Files.copy() method? This apparently also needs
> .toPath() on the names.
> Anyone helping with copy or the absolute path problem would be
> most appreciated.
> Thank you,
> Jeff 
> 
> </body>
> </html>

I have the same problem with HTML files read from directories based in e.g.
my home directory. I believe it is an inherent limitation of most browsers,
which really expect for files to be provided by a web server as opposed to
read directly from the filesystem, and they appear to have no mechanism for
retrieving files from a directory at the 'root' of a local HTML file
hierarchy.
I currently use an absolute path (/home/<username>/...) to accomplish this
because I have found no other solution. I am loath to install something like
Apache just to serve HTML files to myself.

Leslie
--

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Hugh Sweeney

Re: NetRexx, file paths, and copy file

In reply to this post by Jeff Hennick-3

On Wed, 25 Nov 2020 at 15:56, Jeff Hennick <[hidden email]> wrote:

...

This is a general NetRexx question that has come to light in writing a Pipelines stage. First, the problem.

This is in Windows 10, using Firefox as the default web browser.

I have written a stage, DISPLAY, that writes data to a .HTML-file and then uses a system command call to a web browser to display the file by asking the os to open the HTML file. It works fine using the current working directory to store this temporary file. It has been suggested that it would be better to use the system TMP directory for this purpose. OK, I can get its name by using System.getProperty("java.io.tmpdir"). Doing this it also works fine.

But I also want to use an external CSS stylesheet. So I put this line in the HTML file: <link rel="stylesheet" href="'filename'"> . The filename is previously defined as greenbar.css .

If both the HTML file and greenbar.css are in the same directory, i.e. the working or the temporary one, this works.

If I change the filename to a relative path, ./greenbar.css , it works.

The problem is that I would like to have the HTML file in the TmpDir and the CSS file in the working directory (or on a relative path from that). This does not work by any of the ways I can think of.

I haven't seen any replies that provided a solution to any of the questions that you explicitly raised. I can't answer them either so I'm going to make a few assumptions and answer (an)other question(s) that I think might be relevant to you.

One way of looking at your situation is to say that on the one hand you have a pipeline, totally under your control, which has built a HTML sequence that you want rendered as a web page, and on the other hand you have a browser, the internals of which are entirely closed to you, which can render HTML as a web page. You need to pass the HTML from the pipeline to the browser. One way to do that is via the filesystem, but that leads to problems, which you are seeking solutions for.

One assumption that I'm going to make is that this could be an XY Problem (see https://en.wikipedia.org/wiki/XY_problem). This is a term that I've only recently encountered but I've got many years experience of posing XY questions. It could be expressed like this: you have a goal (X): render the HTML and CSS that you have generated; and you believe (as do I) that one way it can be achieved is (Y): by writing your generated data to the filesystem and causing the browser to pick up those files. However, Y does not work in all the scenarios that you want. I believe that Y is not the only way to achieve X, so here goes:

Another way to pass data from your pipeline to a browser is using the HyperText Transfer Protocol (HTTP). It has the advantage that it is well defined (starting with RFC 1945) and all browsers conform to it, rather than each choosing its own defaults. In fact it's the way that browsers usually receive HTML. Leslie Turriff has expressed the same idea but is naturally "loath to install something like Apache just to serve HTML files to myself". Fortunately, this scenario doesn't need anything like the weight of Apache to meet your needs. An HTTP Server that would render your page only needs to field one request from one web browser and unconditionally deliver one stream of HTML, then shut itself down. I could write that in about 10 lines of Java. (That's not the smallest one-shot HTTP server I've seen: on a Linux command line, one could be implemented in 10 characters, using nc.)

A slightly larger HTTP server coded in Java (~60 lines) can be found on p159 of David Flanagan's Java in a Nutshell, Third Edition, ISBN 1-56592-487-8.

Here's what the pipeline would have to do:

choose a TCP port number that's not already in use on your system. Web servers listen by default on port 80 on a HTTP server, and I've found systems running a web server without my prior knowledge (Apache on my Ubuntu laptop; IIS on my Win8.1 tablet). Let's make the port number a configurable variable and call it <portnum> for now.
receive the HTML sequence from whatever stage builds it.
(In Java terms), your HTTP Server must create a ServerSocket to listen on port <portnum> and await a connection on it. Note that this is a blocking wait, so possibly ought to be run on a separate thread from the main pipeline, unless a pipeline wait is acceptable. Flanagan's example demonstrates this. (In CMS terms it's like the built-in pipe stage TCPLISTEN.)
Launch the browser (using the platform-specific command, probably via java.lang.Runtime.exec()) instructing it to connect to a url such as http://localhost:<portnum>. This will cause it to awaken your HTTP Server.
When your HTTP Server is awoken, it is assigned a socket on which it needs to send the HTML sequence as a response. (Roughly equivalent to the CMS TCPDATA pipe stage.)
close the socket and exit.

You will notice that I haven't addressed the question of where you may place the greenbar.css file. For simplicity, I recommend that you store stylesheets and/or other inclusions wherever suits you, but include them inline in the HTML sequence sent to the browser. This allows the conversation between browser and HTTP Server to be limited to one HTTP Request and one HTTP Response. This would mean that the pipeline has extra work to do in implementing some form of ./INCLUDE mechanism. I believe that if you use <link> tags in the HTML sequence you're going to have to cope with parallel requests coming from the browser to the HTTP server, and devise a mechanism to determine when no more requests will be forthcoming, so that the HTTP Server stage may exit. And I'm fairly sure that different browsers will have different quirks in how they support <link> tags (or anything else that may trigger multiple requests), eg serially/parallel, order (fifo/lifo), timeouts etc.

I am confident, perhaps foolishly, that it will be easier to discover the command format to launch a browser, than to discover its internal mechanism for locating files on a filesystem. For instance, on Windows, the default browser can be started with the command start http://localhost:<portnum> , or specifically Firefox: firefox -url http://localhost:<portnum>. (From memory; I can't test them right now.)

You will notice I used the term HTTP Server above rather than web server. The latter has connotations of a lot more functionality, such as multiple protocols, multiple file types and MIME types, multiple requests, binary, encodings, encryption, scripts etc. What I'm proposing is a simple tiny fraction of that. If you get a one-shot HTTP Server working, you can then consider adding other functionality if you think it useful.

Finally, I switched on my computer this morning and read over your original questions and it occurred to me that maybe the file URI scheme (https://en.wikipedia.org/wiki/File_URI_scheme) would help with the questions you posed.

Hugh

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

rvjansen

Re: NetRexx, file paths, and copy file

In reply to this post by Jeff Hennick-3

This Message Is From an External Sender

This message came from outside your organization.

I missed this initially but it is a good thing that Hugh kept it alive.

Probably the best solution here is to load the file from classpath. This way you can have some standard loaded in the NetRexx jar, and give the user (and yourself for that matter) an opportunity to designate a standard css/html directory amd putnit on the classpath variable. You need a speciall call to load a file from the classpath:

InputStream in = this.getClass().getResourceAsStream("/File.css”);

Then you can use, write or copy as you want.

Best regards,

René.

On 25 Nov 2020, at 16:57, Jeff Hennick <[hidden email]> wrote:

This is a general NetRexx question that has come to light in writing a Pipelines stage. First, the problem.

This is in Windows 10, using Firefox as the default web browser.

I have written a stage, DISPLAY, that writes data to a .HTML-file and then uses a system command call to a web browser to display the file by asking the os to open the HTML file. It works fine using the current working directory to store this temporary file. It has been suggested that it would be better to use the system TMP directory for this purpose. OK, I can get its name by using System.getProperty("java.io.tmpdir"). Doing this it also works fine.

But I also want to use an external CSS stylesheet. So I put this line in the HTML file: <link rel="stylesheet" href="'filename'"> . The filename is previously defined as greenbar.css .

If both the HTML file and greenbar.css are in the same directory, i.e. the working or the temporary one, this works.

If I change the filename to a relative path, ./greenbar.css , it works.

The problem is that I would like to have the HTML file in the TmpDir and the CSS file in the working directory (or on a relative path from that). This does not work by any of the ways I can think of.

I have tried using an absolute path of C:/users/jeff/documents/pipe tests/greenbar.css and /users/jeff/documents/pipe tests/greenbar.css . I have even tried putting a copy of greenbar.css in the root directory and using /greenbar.css . None of these have worked.

I have had success with '../../../documents/pipe tests/greenbar.css' , but this requires intimate knowledge of where the TmpDir and the working directory are in the overall tree.

I have come to the conclusion that FireFox refuses to handle absolute paths in this situation, but have not found documentation of this. I have to imagine that other browser and os combinations may also enforce similar rules.

I now come to the workaround of using the TmpDir for both files. This means doing a copyfile of the CSS file from the working directory to the TmpDir. And raises my NetRexx question.

What is the proper, or at least best way, in NetRexx to do a copyfile? Should I use Java's Files.copy() method? This apparently also needs .toPath() on the names.

Anyone helping with copy or the absolute path problem would be most appreciated.

Thank you,

Jeff

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

Jeff Hennick-3

Re: NetRexx, file paths, and copy file

In reply to this post by Hugh Sweeney

Hugh and René,

Thank you both for your very thoughtful and helpful answers.

(I like that XY problem statement. I have done stints "answering that phone." And it came up this week with a question from my brother; where I first answered his explicit question, only later to answer his real one. But I find the Wiki explanation weak. I have posed XY problems. Indeed this one. Stating the Y part was to indicate that I have done some thinking about a solution. Saying all that, stating Y can put blinders on both parties.)

In the mean time I have been digging deeper into my problem.

Having been blinded by my Y, it took a while.

I started by seeing if Java has a builtin CopyFile(). It does not. There were various roll-your-own versions of read-a-line write-a-line, complete with all the overhead of Java. So "NetRexx" was screaming in my brain. Then lightning hit: Pipelines itself!

pipe (filecopy) < filein | > fileout

Bam! Usable in ANY NetRexx program, (in a Pipeline stage, use addpipe instead).

And it worked in testing. At the beginning. Then I discovered a limitation with the current diskr and diskw stages. They don't work with files with absolute path specifications.

So, right now, I am working on bug fix for those stages. And once again deep into Java's pickiness.

This is what I currently have as a work in progress is this. (Re variable names: "a" is the argument of the filename in the existing code; other names come from copied code; some I just made up. I expect to change names to be more readable prior to publishing.)

         if a.pos('/') + a.pos('\\') > 1 then do   -- we are working with a filepath out of the working dir
            filePath = File("").getAbsolutePath() -- find out where the working directory is
            a = filePath || '/' || a               -- make a messy absolute path for our file
            as = String a.changestr("\\","/")      -- fix any Windows spec
            af = File(as)                          -- have Java realize we are working with a file
            do                                     -- clean up the path to get rid of ./ and ../
              ap = Paths.get(af.getCanonicalPath())
            catch java.io.IOException
            end
            a = Paths.get(filePath).relativize(ap) -- bring it relative to the current working dir
          end

========

The second problem I am facing is getting addpipe() to recognize and work with {var} as an outside NetRexx variable name. Right now, it is seemingly sporadic, and I have not tracked it down. I need to be able to:

addpipe (filecopy) < {filein} | > {fileout} ?

And two bugs in addpipe() have showed up:

A pipeend character, ?, at the end of the addpipe (as above) specification does not work. It must be removed.
A comment stage, --, is not recognized.

I'll have to dig into where ever addpipe is defined. I suspect that runpipe will need it too.

Again, thank you for all the help and obvious time you have put in. (Maybe someday I'll get back to my original problem.)

Jeff

On 11/29/2020 4:54 AM, Hugh Sweeney wrote:

On Wed, 25 Nov 2020 at 15:56, Jeff Hennick <[hidden email]> wrote:

...

This is a general NetRexx question that has come to light in writing a Pipelines stage. First, the problem.

This is in Windows 10, using Firefox as the default web browser.

I have written a stage, DISPLAY, that writes data to a .HTML-file and then uses a system command call to a web browser to display the file by asking the os to open the HTML file. It works fine using the current working directory to store this temporary file. It has been suggested that it would be better to use the system TMP directory for this purpose. OK, I can get its name by using System.getProperty("java.io.tmpdir"). Doing this it also works fine.

But I also want to use an external CSS stylesheet. So I put this line in the HTML file: <link rel="stylesheet" href="'filename'"> . The filename is previously defined as greenbar.css .

If both the HTML file and greenbar.css are in the same directory, i.e. the working or the temporary one, this works.

If I change the filename to a relative path, ./greenbar.css , it works.

The problem is that I would like to have the HTML file in the TmpDir and the CSS file in the working directory (or on a relative path from that). This does not work by any of the ways I can think of.

I haven't seen any replies that provided a solution to any of the questions that you explicitly raised. I can't answer them either so I'm going to make a few assumptions and answer (an)other question(s) that I think might be relevant to you.

One way of looking at your situation is to say that on the one hand you have a pipeline, totally under your control, which has built a HTML sequence that you want rendered as a web page, and on the other hand you have a browser, the internals of which are entirely closed to you, which can render HTML as a web page. You need to pass the HTML from the pipeline to the browser. One way to do that is via the filesystem, but that leads to problems, which you are seeking solutions for.

One assumption that I'm going to make is that this could be an XY Problem (see https://en.wikipedia.org/wiki/XY_problem). This is a term that I've only recently encountered but I've got many years experience of posing XY questions. It could be expressed like this: you have a goal (X): render the HTML and CSS that you have generated; and you believe (as do I) that one way it can be achieved is (Y): by writing your generated data to the filesystem and causing the browser to pick up those files. However, Y does not work in all the scenarios that you want. I believe that Y is not the only way to achieve X, so here goes:

Another way to pass data from your pipeline to a browser is using the HyperText Transfer Protocol (HTTP). It has the advantage that it is well defined (starting with RFC 1945) and all browsers conform to it, rather than each choosing its own defaults. In fact it's the way that browsers usually receive HTML. Leslie Turriff has expressed the same idea but is naturally "loath to install something like Apache just to serve HTML files to myself". Fortunately, this scenario doesn't need anything like the weight of Apache to meet your needs. An HTTP Server that would render your page only needs to field one request from one web browser and unconditionally deliver one stream of HTML, then shut itself down. I could write that in about 10 lines of Java. (That's not the smallest one-shot HTTP server I've seen: on a Linux command line, one could be implemented in 10 characters, using nc.)

A slightly larger HTTP server coded in Java (~60 lines) can be found on p159 of David Flanagan's Java in a Nutshell, Third Edition, ISBN 1-56592-487-8.

Here's what the pipeline would have to do:

choose a TCP port number that's not already in use on your system. Web servers listen by default on port 80 on a HTTP server, and I've found systems running a web server without my prior knowledge (Apache on my Ubuntu laptop; IIS on my Win8.1 tablet). Let's make the port number a configurable variable and call it <portnum> for now.

receive the HTML sequence from whatever stage builds it.

(In Java terms), your HTTP Server must create a ServerSocket to listen on port <portnum> and await a connection on it. Note that this is a blocking wait, so possibly ought to be run on a separate thread from the main pipeline, unless a pipeline wait is acceptable. Flanagan's example demonstrates this. (In CMS terms it's like the built-in pipe stage TCPLISTEN.)

Launch the browser (using the platform-specific command, probably via java.lang.Runtime.exec()) instructing it to connect to a url such as http://localhost:<portnum>. This will cause it to awaken your HTTP Server.

When your HTTP Server is awoken, it is assigned a socket on which it needs to send the HTML sequence as a response. (Roughly equivalent to the CMS TCPDATA pipe stage.)

close the socket and exit.

You will notice that I haven't addressed the question of where you may place the greenbar.css file. For simplicity, I recommend that you store stylesheets and/or other inclusions wherever suits you, but include them inline in the HTML sequence sent to the browser. This allows the conversation between browser and HTTP Server to be limited to one HTTP Request and one HTTP Response. This would mean that the pipeline has extra work to do in implementing some form of ./INCLUDE mechanism. I believe that if you use <link> tags in the HTML sequence you're going to have to cope with parallel requests coming from the browser to the HTTP server, and devise a mechanism to determine when no more requests will be forthcoming, so that the HTTP Server stage may exit. And I'm fairly sure that different browsers will have different quirks in how they support <link> tags (or anything else that may trigger multiple requests), eg serially/parallel, order (fifo/lifo), timeouts etc.

I am confident, perhaps foolishly, that it will be easier to discover the command format to launch a browser, than to discover its internal mechanism for locating files on a filesystem. For instance, on Windows, the default browser can be started with the command start http://localhost:<portnum> , or specifically Firefox: firefox -url http://localhost:<portnum>. (From memory; I can't test them right now.)

You will notice I used the term HTTP Server above rather than web server. The latter has connotations of a lot more functionality, such as multiple protocols, multiple file types and MIME types, multiple requests, binary, encodings, encryption, scripts etc. What I'm proposing is a simple tiny fraction of that. If you get a one-shot HTTP Server working, you can then consider adding other functionality if you think it useful.

Finally, I switched on my computer this morning and read over your original questions and it occurred to me that maybe the file URI scheme (https://en.wikipedia.org/wiki/File_URI_scheme) would help with the questions you posed.

Hugh

--
_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/