Display graphical files from CGI-script

[Willem Grooters]

My web-appliaction consists of dymanic data, created using a CGI-script. Some data may be linked to an image I want to display. I have been able to create a link in dynamic context, and I succeeded in launching the picture onto the screen directly from the CGI-script; only, not as a picture, but "as is" - in text.
I followed the specification in the SWS user manual http://h71000.www7.hp.com/openvms/products/ips/apache/csws_iguide.html Paragraph 3.14.5:
$ APACHE$FLIP_CCL
$ WRITE SYS$OUTPUT F$FAO("!as!/!/","CONTENT-TYPE: IMAGE/GIF")
$ APACHE$DCL_BIN APACHE$ROOT:[ICONS]APACHE_PB.GIF

as an example, but that does not help. It shows me:
GIF89a ÷ÿÿÿÎÎÎ¥¥¥„„„ssskkkZZZ! ÿB ÿ1½R Þ­„ïœBÿ„ÿÎ ÿÎÎÎƽ½Æ1ÿcÿœÿïÿçJïÞ(and so on)

in stead of the image.

Have I missed something?

[David Jones_21]

Which browsers have you tried it with, some browsers(i.e. IE) arbitrarily ignore the content type based on how the URL ends. Also, try using lower case for the content type.

[Rick Retterer]

Willem,
Yup you sure have. The example is not really correct. Give this a try:

$ APACHE$FLIP_CCL
$ WRITE SYS$OUTPUT F$FAO("!AS!/!/","CONTENT-TYPE: IMAGE/GIF")
$ MCR APACHE$COMMON:[000000]APACHE$DCL_BIN APACHE$ROOT:[ICONS]APACHE_PB.GIF
$ EXIT

The main thing you will want to change in your command procedure is line #3

SWS doesn't understand the command: APACHE$DCL_BIN... So you have to make it a executable command. To do that in VMS, simply use the MCR command, followed by the full path to the executable... then followed by the path/filename of your gif file.

$ mcr apache$common:[000000]apache$dcl_bin->
apache$root:[icons]apache_pb.gif

Hope this helps you!

Cheers,
Rick Retterer
HP Services
OpenVMS/Tru64 Unix Graphics/Java/SWS Support.

[Bojan Nemec]

Rick,

I dont think that the problem is the APACHE$DCL_BIN command. If this will be a problem the content will not be GIF89a... but
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\APACHE$DCL_BIN\

Willem is the lowercase "!as!/!/" a typo in yours post? If this is in yours command procedure try to replace it with "!AS!/!/".

Bojan

[Willem Grooters]

David:
IE indeed. The final file will be .jpg, but "content-type: image/jpg" does the same thing (with a jpeg file of course), case doesn't matter:

content-type: image/jpg à ÿà JFIF ddÿþ Adobe ImageReadyÿì Ducky Fÿî Adobedà ÿÃ
and so on.
Using another browser is no option.

Rick:
I didn't miss a thing, the documentation does, the text I show before is cutted and pasted from the documentation. It should read:
$ MCR APACHE$COMMON:[000000]APACHE$FLIP_CCL.EXE_ALPHA
$ WRITE SYS$OUTPUT F$FAO("!AS!/!/","CONTENT-TYPE: IMAGE/GIF")
$ MCR APACHE$COMMON:[000000] APACHE$DCL_BIN.EXE_ALPHA APACHE$ROOT:[ICONS]APACHE_PB.GIF

Anyway - that didn't work either.

Perhaps this is of importance as well, I'm not sure: The image is to be displayed in a frame that contains text. I would prefer a pop-up window containing just that image, but I haven't found a way to do that: the page containing the link is generated by a program (but I can change that, if only I knew hor to create that pop-up window)

[Willem Grooters]

Bojan,
NO typo: it is specified in the documentation...
I didn't get the error message, I think that the APACHE subprocesses have this set up as foreign commands. I cound't find it in any apache log either.

[Bojan Nemec]

Willem,

In my previous post I mean that if you type in DCL prompt:

$ WRITE SYS$OUTPUT F$FAO("!as!/!/","CONTENT-TYPE: IMAGE/GIF")
%SYSTEM-F-BADPARAM, bad parameter value
\!as!/!/\

but if you type:

$ WRITE SYS$OUTPUT F$FAO("!AS!/!/","CONTENT-TYPE: IMAGE/GIF")
CONTENT-TYPE: IMAGE/GIF


And, maybe two empty lines also give some problems. Try with:
$ WRITE SYS$OUTPUT F$FAO("!AS!/","CONTENT-TYPE: IMAGE/GIF")


Bojan

[David Jones_21]

>>And, maybe two empty lines also give some problems. Try with:
$ WRITE SYS$OUTPUT F$FAO("!AS!/","CONTENT-TYPE: IMAGE/GIF")<<

No, don't try that. The blank line is part of the CGI protocol that delimits the header lines from the data.

[Bojan Nemec]

David,

I know that a blank line is part of the CGI protocol (or less specific HTTP protocol). The blank line ends the header lines and starts the data part. (I think that CGI sends its headers and redirect all the output from the CGI script to the browser). But when you execute the command:

$ WRITE SYS$OUTPUT F$FAO("!AS!/!/","CONTENT-TYPE: IMAGE/GIF")

you receive:
CONTENT-TYPE: IMAGE/GIF



The first two pairs are added by FAO and the last one by WRITE! So you have two blank lines and not one which is required by the HTTP protocol. When you have html or text files this is not a problem. But how will the server and/or browser interpret the extra blank line? It will ignore it or will interpret the line as data?

GIF89a...
is not the same as
GIF89a...

Bojan

[Willem Grooters]

How I would like to have a browser that just dumped all received data in HEX format, like the VMS DUMP command....

Anyway, I found a workaround that is sufficient for now: Define the location of the file as an alias in httpd.conf, and refer to that alias. I ran into other problems there, mentioned in another thread.
But I would have a solution where differences in environment are kept OUTSIDE the configuration of the webserver, and are handled by the CGI-script. Including display of images.

[David Jones_21]

$ WRITE SYS$OUTPUT F$FAO("!AS!/!/","CONTENT-TYPE: IMAGE/GIF")

you receive:
CONTENT-TYPE: IMAGE/GIF


>>
The first two pairs are added by FAO and the last one by WRITE! So you have two blank lines and not one which is required by the HTTP protocol.<<

FAO does not add a newline. The write to sys$output normally adds an implied newline, but this is inhibited by the APACHE$FLIP_CCL.

>>When you have html or text files this is not a problem. But how will the server and/or browser interpret the extra blank line? It will ignore it or will interpret the line as data?<<

If the problem was an extra newline, the browser would display a 'broken image' image icon. Since the browser is trying to display the data as text, the content-type is not getting conveyed properly.

Willem,
Are we seeing the entire script source (i.e. there are no writes to sys$output preceding the apache$flip_ccl line)?

[Bojan Nemec]

Willem,

What abbout:

$ TELNET server_ip 80/LOG=HTTP_LOG.LOG
GET /path/to/cgi HTTP/1.0

$ DUMP HTTP_LOG.LOG


Replace server_ip with yours APACHE server ip (if it is not running on port 80 also replace the port). Replace the "/path/to/cgi" with the path to the cgi script. You must type the line and end with two returns. In several cases the line is not displayed, so it is best to write it before and past it (delete does not work:).

Bojan

[Steven Schweda]

> $ TELNET server_ip 80/LOG=HTTP_LOG.LOG
> GET /path/to/cgi HTTP/1.0
>
> $ DUMP HTTP_LOG.LOG

Wget may be easier than Telnet if you plan to
do this often.

http://antinode.org/dec/sw/wget.html

[Willem Grooters]

David,

Indeed, I have a line:
$ write sys$output f$fao("!/")
but removing that gives me "Internal Server Error". Since the procedure is used for all access, it blocks the application COMPLETELY.

(I could think of another script to be started, but the code that generates the HTML would than need a more major update. keep in mind I need to define the logical environment - inclusing WHERE to get the image. I prefer to have a pop-up, and NO appliaction references in httpd.conf, and no version dependent ones at all - as I'm forced to do now (see http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=973272))

[Robert Atkinson]

Willem, as has been loosely referred to already, this is a problem with I.E.

I.E. doesn't like to adhere to the W3C Content Header standards. Instead it prefers to use the URL.

The attached code handles files for these MIME types :-

(LNM$SYSTEM_TABLE)

"WEBREPORT$MIMETYPE_CSV" = "text/plain"
= "TEXT"
= "SAVE"
"WEBREPORT$MIMETYPE_LOG" = "text/plain"
= "TEXT"
"WEBREPORT$MIMETYPE_PDF" = "application/pdf"
= "BINARY"
"WEBREPORT$MIMETYPE_SPF" = "text/plain"
= "TEXT"
"WEBREPORT$MIMETYPE_SPL" = "text/plain"
= "TEXT"
"WEBREPORT$MIMETYPE_TXT" = "text/plain"
= "TEXT"
"WEBREPORT$MIMETYPE_XLS" = "application/vnd.ms-excel"
= "BINARY"
"WEBREPORT$MIMETYPE_ZIP" = "application/octet-stream"
= "BINARY"
= "SAVE"


In order to make it work in I.E., I also append '&/filename.ext' to the URL when requesting the file.

Rob.

[Willem Grooters]

David have me a right hint - NO text before "content-type" - at all. I decided to follwo that and the solution I found (before reading Robert's reply) was using another procedure that will just set the content type and dump the binary onto SYS$OUTPUT - as stated before. This is more in linme with the wanted solution, to have images in a separate window. More important: I now don't need any application- nor version dependency in httpd.conf.