[Info-vax] proper file format, attributes for non-binary files served by a web server

[Steven Schweda]

On Jan 21, 11:13 am, hel... at astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> In article
> <882908ae-9224-4a88-9de9-32b10b66a... at q8g2000yqa.googlegroups.com>,
>
> Steven Schweda <sms.antin... at gmail.com> writes:
> >    When dealing with any program which uses the C RTL,
> > Record format: Stream_LF will be most natural.  For general
> > portability reasons, I try to use Stream_LF format for any
> > text files which will get sent to a non-VMS system.
>
> But this is not necessary for with files on VMS which are never
> transferred elsewhere EXCEPT VIA WWW, right?

   Around here, a file which gets served by the Web server
may also get served by the FTP server, and it might also get
put into a Zip archive.  Perhaps every program can handle
variable-length records properly, and perhaps not.  I would
rather have Stream_LF files everywhere, and not have to think
any more about them.

   My worst problem is when I create a new file (like, say, a
new UnZip or Zip source module) with an editor, and then I
need to remember to run my NON-STMLF.COM DCL procedure, which
looks for files where:
      f$file_attributes( file, "RFM") .nes. "STMLF"
(I also have a CNVSTMLF.COM, which uses CONVERT /FDL to make
a Stream_LF file from a non-Stream_LF file.)

   In principle, Info-ZIP UnZip on a non-VMS system should be
built with the VMS_TEXT_CONV option enabled, so it should be
able to decode a VMS var-len file, but non-Info-ZIP programs
may not have the same capability.  Again, with a Stream_LF
file, I don't need to worry.

> Where else are byterange requests used?

   I don't know who uses what where or when.  I see many
"206" result codes in my Web server log, so I assume that
someone is asking for less than a whole file sometimes.
(Mostly ".pdf" or ".zip", but others, too.)