Re: reading pdf/html from ifs send via cgidev2

On 12/28/06, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote:

> I'm not familiar with the Location: header technique, but I'm not sure
> what you mean by it being just a link to the document.

A Location: field is an HTTP header field that causes the browser to
"redirect" to a different spot.  For example you could change your code to
look like this:

C                   eval      OutStr = 'Location: '
C                             + '/webdirectory/pdfs/mypdffilename.pdf'
C                             + $CrLf + $CrLf
C                   exsr      $APIStdOut

Though, there's a difference... yours opens in a separate window.  Thsi
just tells the browser to go to a different location, but it stays in the
same window.

I gotcha now.  In my application, I wanted the submit page to remain
where it was, and have this one open in a new window.  I remember the
location: command now.  it's been a while.

> It's my assumption that he's creating these pdfs on the fly - based on
> selection criteria prompted from a browser.  when the user hits the
> submit button, the cgi runs, generates the report and converts it to
> pdf.  now the user needs to see it, so my solution automatically opens
> a browser window with the pdf file's path and name already embedded.

What happens if two users run the CGI program at once?   Won't the PDF
file in the IFS be overwritten by the 2nd user, causing the first one to
get a strange response?

In my case, I created the file name uniquely - a sequence number or
some other identifying attribute so there would be no conflicts.

Couldn't a malicious user use
this against you by filling up your hard drive with lots and lots of PDFs,
potentially causing your system to crash?

yes of course they could.  without a doubt, this would have to be, and
could easily be addressed.

This is why I go back to the same thing each time.  If you're going to
generate the document on-the-fly, why write it to the IFS?  Just write it
directly to the browser!

> If all you are looking for is just a web inquiry, then writing the
> report results in HTML is certainly an option.  But if you want to
> print the output, html reports are not printer friendly, pdfs are.

I don't understand why you're bringing this up?  Did someone dispute the
validity of PDF as an option?  I certainly didn't.

then I stand corrected, I'm not aware of any way to write pdfs
directly to the browser.  that of course, would be the optimum
solution.