Apache (csws) PDF JPG GIF file size limited

Having difficulties when installing the system? Your system runs slowly and requires some tweaking? You can get help here.
Post Reply

Topic author
cfd
Visitor
Posts: 2
Joined: Mon Mar 15, 2021 2:14 pm
Reputation: 0
Status: Offline

Apache (csws) PDF JPG GIF file size limited

Post by cfd » Fri Mar 26, 2021 3:31 pm

After upgrade from HP vms8.3-1 and HP CSWSv2.2-1 (2014)
to VSI vms8.4-2L1 and VSI CSWSv2.4-3 on a rx2800,
web files larger than 55 blocks (estimated) are not delivered intact to various browsers.

For example, a 181.block GIF file appears blank on Firefox, but appears 1/2 OK and 1/2 missing on Chrome.
PDF files saved by Firefox can not be opened by Acrobat ("damaged").
The web site is presently http rather than https .
No errors appear in the Apache error lots.

Any suggestions as to (e.g.) Apache httd.conf settings which might mitigate this
error would be greatly appreciated.
Fred Driscoll


hein
Active Contributor
Posts: 41
Joined: Fri Dec 25, 2020 5:20 pm
Reputation: 0
Status: Offline

Re: Apache (csws) PDF JPG GIF file size limited

Post by hein » Sat Mar 27, 2021 5:13 pm

May we assume that the test involved exactly the same files, before and after the upgrade?

Any C-RTL logicals configured such as
DECC$DEFAULT_LRL 32767
DECC$DEFAULT_UDF_RECORD DISABLE
DECC$FIXED_LENGTH_SEEK_TO_EOF DISABLE
for details see-
https://vmssoftware.com/docs/VSI_C_RTL_REF_MAN.pdf

Are there any (RMS) errors to be found in the logs?

The 55 blocks mentioned is relatively close to the RMS maximum record size of 32767 (64 blocks minus 1 byte)
What are the typical file attributes for files to be served up? Stream_lf? fixed-512?

If a stream_lf file is read in RECORD mode, then you would expect it to fail when larger than 64 block due to 'missing terminator', but all sorts of errors may be reported.

Here is one way to test this.
Create a large file with 'raw' data simply by using a large fixed length (even preferred) record size:

$ conv/fdl="rec; form fix; size 30000"/pad="X" tt: tmp.tmp/stat
aap-
noot-
mies-

Now read it with the C-rtl for example using Perl

$ perl -ne "$len +=length }{ print qq(len=$len, recs=$.)" tmp.tmp
len=90003, recs=3

3 records as expected, and dhose 3 bonus bytes? "free" semi-instantiated record terminators

Now fake it as a stream_lf file which the C-rtl will treat as a byte stream file:

$ set file/attr=rfm=stmlf tmp.tmp
$ perl -ne "$len +=length }{ print qq(len=$len, recs=$.)" tmp.tmp
len=90000, recs=1

Cute?

Now try RMS .... all sorts of errors:

%TYPE-W-READERR, error reading TMP.TMP
-RMS-W-RTB, 90000 byte record too large for user's buffer
%TYPE-F-WRITEERR, error writing NL:[]TMP.TMP;
-RMS-F-RSZ, invalid record size

$ searc/log/win=0 tmp.tmp ""
%SEARCH-I-TRUNCATE, record(s) in TMP.TMP truncated to 32768 bytes
%SEARCH-S-MATCHED, TMP.TMP - 1 record, 1 match

$ conv/stat tmp.tmp nl:/fdl=nl:
%CONVERT-I-RTL, record longer than maximum record length
$ dir/size new.tmp,tmp.tmp;
NEW.TMP 65
TMP.TMP 176

Good luck!
Hein


brett.cameron
VSI Expert
Active Contributor
Posts: 25
Joined: Mon Jun 24, 2019 9:51 am
Reputation: 0
Status: Offline

Re: Apache (csws) PDF JPG GIF file size limited

Post by brett.cameron » Sat Mar 27, 2021 5:19 pm

That's a very old CSWS version (V2.4-3) and I seem to recall that this might have been a known issue. Suggest using a later kit (https://vmssoftware.com/openkits/i64ope ... D-1.ZIPEXE).


Topic author
cfd
Visitor
Posts: 2
Joined: Mon Mar 15, 2021 2:14 pm
Reputation: 0
Status: Offline

Re: Apache (csws) PDF JPG GIF file size limited

Post by cfd » Sat Mar 27, 2021 8:26 pm

The newer VSI-I64VMS-CSWS-V0204-38D-1 install kit seems to have completely solved the problem.

Brett, thanks for the pointer to the kit. I note that the I640842L1U1 install kit for VSI-VMS presently includes the old CSWSv0204-3-1 kit, and the recent i640842LP disc does not include CSWS.

Hein, thanks for the interesting suggestions for RMS tests. I learned a little, but as a physicist with 30 years VMS "management-as-needed", RMS still stands for Root.Mean.Square :)

Thanks again; a clean-runnign VMS is a wonderful thing.
Fred
Fred Driscoll

Post Reply