Apache / CSWS problems with Safari / Chrome / Opera

Kelly Cox · ‎01-16-2015

I recently tested some cgi script pages with FireFox (FF), IE, Safari, Chrome, Opera.

They have worked in the past on all 5 browsers. They work fine still on FF and IE, but randomly only paint partial pages on nothing on Safari, Chrome, and Opera. I guess FF and IE are being more lenient.

I made a simple test page:

<!Doctype html>

<html>

hello world

</html>

Itanium, VMS 8.4, CSWS 2.2-1, TCPIP 5.7-13ECO4

apache config with very few changes from default.

using chrome and opera i get error: net::ERR_INCOMPLETE_CHUNKED_ENCODING

safari returns error: kCFErrorDomainCFNetwork error 303.

I'm searching on these errors and LOTS of folks with LOTS of same error with LOTS of different reasons.

I'm thinking it's not just new versions of browsers, but I need to learn more about apache config on VMS.

All advice and pointers will be greatly appreciated.

Steven Schweda · ‎01-16-2015

> [...] randomly only paint partial pages [...]

   Not a very detailed description of the circumstances or the behavior.

> I made a simple test page:
> [...]

   Is that a static file, or what you think is coming out of your CGI
script (written in what?), or what?

> They have worked in the past on all 5 browsers. [...]

   Define "the past". What's changed since then?

> using chrome and opera i get error: [...]

   Doing what, exactly? Where? Browser output/display? Pop-up
complaint? I don't think that I have enough information to duplicate
(or even approximate) your environment.

   I made a static file like what you posted, and had no trouble with it

in Safari Version 8.0.2 (10600.2.5). It may not matter, but my usual
minimal test page is a little less minimal than yours:

ALP $ type test.html
<HTML>
<HEAD>
<TITLE>Antinode Test</TITLE>
</TITLE>
</HEAD>
<BODY>
<P>
Only a test.
<HR>
</BODY>
</HTML>
ALP $

If you're doing this with a CGI script, then you might want to use a
(relatively) simple tool like Wget to see what's actually coming back.

Or Telnet to port 80, and send an appropriate GET command.

> I'm thinking [...]

   As a wise man (guy?) once said, "If you don't think too good, don't
think too much." Actual test results are often more helpful than
guesswork.

   Around here:

ALP $ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.6 - ECO 5
on a COMPAQ Professional Workstation XP1000 running OpenVMS V8.3

ALP $ product show product csws
------------------------------------ ----------- ---------
PRODUCT                              KIT TYPE    STATE
------------------------------------ ----------- ---------
CPQ AXPVMS CSWS V2.1-1               Full LP     Installed

------------------------------------ ----------- ---------

1 item found

Kelly Cox · ‎01-17-2015

The test html code i posted was static html, no cgi involved.

I have not changed the csws config in over a year except to test some virtual hosts about 9 months ago.

In October or November the cgi generated pages were tested with opera and chrome and they were fine.

Testing with IE and FF and Safari is done on a monthly basis and at times more often. I think all browsers update every time I turn the test pc or mac on. Chrome version 39.0.2171.99 m, Opera version 26.0.1656.60, ipad and MacBook and iMac are at home so i can't get list Safari version right now.

Late December I noticed that my wife's ipad showed error:

kCFErrorDomainCFNetwork error 303.

I started testing the other browsers this week and opera and chrome just showed blank windows. When I use the browsers EXAMINE ELEMENT debug tool i get the error: net::ERR_INCOMPLETE_CHUNKED_ENCODING

So I made a simple static web page to put on the rx2600 I64. I got same blank windows and same errors. So i made the static html text REAL simple...same errors.

I then created that same static page on a different rx2600 I64 running VMS 8.4 and same tcpip and same CSWS, but with CSWS setup as a very basic config as it comes from HP with only the ip address as the serverName changed. This setup exhibits the same errors and blank page, but now served from 2 different servers.

Internet searches on these errors from many different forums list many different threads that complain of the same error. Some of those listed certain Chrome settings they had to turn off, so I turned those off and the error remains.

Other forum threads listed virus software or other browser add-ons that caused this same error, but I had none of that running. Some threads listed certain apache or windows http server settings that they had to turn on like MOD_REWRITE, so i tried turning that on and off in CSWS.

The screens load VERY fast in FF and IE. In Chrome, if i refresh the page it will partially load perhaps 3 out of 20 tries and fully load 1 out of 20. The one time it loads it will be VERY fast, the other times the cursor will spin for a minute until the error pops up. There is no remote style sheets to load, no js or jquery or other libraries to load, just basic html for the static test, so what could be causing the large timeout?

I am learing more about apache as I have read the docs on mod_rewrite and a few other modules that forums have mentioned.

80% plus of the clients that load my production pages are IE and FF, and I have had no complaints yet, but they will come as Safari makes up almost the rest of the 20%. I am guessing that some of the browsers have become stricter on some rule and I need to change my CSWS config.

Thanks in advance. kc

Hoff · ‎01-17-2015

The chunked stuff from within HTTP 1.1 is basically the RMS VFC file data scheme (record length prefix on the data record, repeat until end of data), so it'd seem there's something wonky with how that data is being provided from the server, or possibly in the various caches. There are all sorts of reasons, unfortunately, and it can be because of how the client asked for the data, or a result of how the server generated the data, or something with the server cache.

Use Safari's web inspector (from the Safari developer menu) or use Firefix Firebug or a MitM proxy that can log the data streams, or maybe tcpdump, and have a look at the HTTP data streams. See if the data streams are valid or not.

I've tested your HTML on a newer Apache (2.2.26) server, and it (unsurprisingly) works fine.

HP's VMS web site is redirecting their open source link back to the originating web page, so it'll take a little digging to figure out what's going on with a test server here; I have CSWS V2.2 UPDATE 2.0 installed and not something that calls itself V2.2-1. I think that what I have is older, but then I'm not entirely certain of that without also rummaging around on HP's FTP server and then some test installs for confirmation.

Kelly Cox · ‎01-17-2015

Thanks for the repl Hoff,

There is a LOT of middleware these days to get in the way.

I updated 2 of my servers from CSWS 2.2 update 2.0 to version 2.2-1 in the fall of 2014.

I updated the test server, then the production server after all looked good.

I used the following download.

hp-i64vms-csws-v0202-1-1.pcsi_sfx_i64exe;1 blocks=33453 30-OCT-2014 12:52:58.39

I guess i better login and see if there are any recent patches/updates.

I have been using firebug in firefox, but i'm just learning that tool, so I haven't stumbled on an answer yet.

I posted this thread, because i'm not usually leading edge anything, and I hoped that some of you brainiacs have seen this and could point me in the correct direction.

The CSWS logs don't seem to tell me anything if I am reading them correctly, they say status 200, basically data served correctly i think.

Hoff · ‎01-18-2015

If you're showing this with static HTML on Apache, then the only software involved here is the server and the browsers, or some filtering or caching software in your local network path. Got any firewalls or any nanny filters in the path to the server? Are there any client-side packages claiming to provide "anti-virus" or "anti-malware" features involved here?

I generally avoid configuring the VMS Apache port on public-facing servers, and for a variety of reasons not the least of which is the outdated SSL/TLS support in the current version. Should VSI or another entity port a far more current version of Apache, I'll reconsider that. "Anti-virus" and "anti-malware" software can sometimes disrupt HTTP transfers, as well.

It appears that HP has discontinued use of the existing FTP area for the Apache kit downloads and the Apache sources, and has implemented a different (new) download path. There are no sources for the V2.2-1 kit posted anywhere obvious, either.

Kelly Cox · ‎01-19-2015

There should be no anti-virus or anti-malware software running, nor any firewall or caching that is intentional.

I have turned off all options in Chrome that I can find.

I run apache on VMS only so I can have a test environment that mirrors closely what most of my education based clients are using.

The release notes for CSWS 2.2-1 has a cache related warning:

- Cached files not served
- The proxy cache feature does not serve the cached files in SWS Version 2.2-1.

I added some meta tags based on some forum suggestions about cache:

meta http-equiv="cache-control" content="max-age=0"
meta http-equiv="cache-control" content="no-cache"
meta http-equiv="cache-control" content="no-store"
meta http-equiv="expires" content="0"
meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT"
meta http-equiv="pragma" content="no-cache"

...and these did not help.

In firebug the http request is very simple and the return also looks normal and minimal.

After I figure out how to see this type of debug info with safari and chrome i will compare those.

I'm very tempted to un-install 2.2-1 and put one of these servers back to apache 2.2 and see if that makes a difference.

I'm also tempted to install WASD and serve via a different port on the same server and see if WASD makes a difference.

Thanks again for all advice. kc

Craig A Berry · ‎01-19-2015

FWIW the current CSWS kits are available where they've always been at:

http://h71000.www7.hp.com/openvms/products/ips/apache/csws_download.html

Release notes are at:

http://h71000.www7.hp.com/openvms/products/ips/apache/csws_relnotes_22.html

I did not see up-to-date source kits after a quick glance.

Jur van der Burg · ‎01-19-2015

If you clear the cache of your browser, does that help?

it may be a caching thing. If you do not send any info about expiration from the server to the browser then a browser is free to interpret it anyway it likes. Firefox for example will in that case always use a cached copy, even though the file on the server may be newer. That's a nightmare if you update files on the server, and the browser will use stale info. Clearing the browser's cache will work around that.

The real solution may be to use mod_headers in apache, for example like this:

<IfModule mod_headers.c>
Header merge Cache-Control must-revalidate,no-cache
</IfModule>

This means that the browser must contact the server to check if there's newer data, and it may only use the cached copy if that's not the case. Otherwise it will get the new contents.

Fwiw,

Jur.

Hoff · ‎01-19-2015

@Craig A Berry wrote:
FWIW the current CSWS kits are available where they've always been at:

http://h71000.www7.hp.com/openvms/products/ips/apache/csws_download.html

I did not see up-to-date source kits after a quick glance.

FWIW, the V2.2-1 kit is not in the usual FTP area (ftp.hp.com/pub/openvms/apache), nor is the source kit available there.

Kelly Cox · ‎01-23-2015

No, this does not help either.

One of the first things I tried on all the browsers is clearing the cache, and setting no-cache.

Thanks for the input.

Kelly Cox · ‎01-23-2015

I stumbled on the answer.

Warning.......SWS 2.2-1 REQUIRES served files to be in STREAM_LF again. I verified that I had MMAP set to off in the apache directive...yet it still times out and throws the CHUNK ENCODING error if you use non stream_lf text files... when using Chrome or Opera or Safari. IE and FireFox seem to handle the files.

The install guide for this version and for versions 2.1 and 2.2 say this is NOT a requirement anymore.

And when I'm creating a quick test of style sheets or html and javascript i still mostly use edit/tpu on VMS.

My production box we have always been careful to convert all files to stream_lf because it seems to make everything quicker, but for creating a quick test, it has not been necessary for a few years now.

Anyway, simple fix, but the install doc should reflect this change back to old behavior.

Steven Schweda · ‎01-23-2015

> Warning.......SWS 2.2-1 REQUIRES served files to be in STREAM_LF
> again. [...]

   Somewhere along the line, I quit trusting it, and have since tried
to stick to Stream_LF.

> And when I'm creating a quick test of style sheets or html and
> javascript i still mostly use edit/tpu on VMS.

   Same here, but I've developed the habit of:

      edit /tpu any_old_good_file /output = new_file

which creates the new file with the attributes of the old file.
Naturally, my test.html was "Record format: Stream_LF".

   For more organized work, I use MMS to generate my actual Web-served
HTML files by running source files through a preprocessor (a C program)
which (among other things) puts out a Stream_LF file, so the attributes
of a source file matter little. In other situations (freeware source
files, for example, which might end up getting served), I have a DCL
script which will search a directory tree for files where:

      if f$file_attributes( file, "RFM") .nes. "STMLF"

It emits a message identifying the culprit. Not automatic, but useful.

Hoff · ‎01-24-2015

@Kelly Cox wrote:

Anyway, simple fix, but the install doc should reflect this change back to old behavior.

It would probably be better if the CSWS/SWS test suite was updated to reflect this.

Neil Rieck · ‎07-28-2015

FWIW, "stream_lf" is not a requirement for CSWS-2.2 on Alpha (it wasn't on 1.3 but was on 2.0 then removed again in 2005 with the release of 2.1). Now I've got a brand new Itanium (rx2800-i2) and want to move over a huge amount of content from the Alpha but I can't because I am stuck with a "limping" web-server. "I think" I only two options: Build a version of v2.2 by installing V2.1 then applying updates -OR- converting all the content to stream LF. Has anyone tried building 2.2 on Itanium?

Steven Schweda · ‎07-28-2015

> [...] converting all the content to stream LF. [...]

   As I said, I long ago gave up on using any other format.

   If you're already planning to move the stuff, and the stuff is all
text files, then you might be able to get the conversion done at low
cost using Zip (3.x) and UnZip (6.x). For example:

alp $ write sys$output f$file_attributes( "text.txt", "RFM")
VAR

alp $ zip3l text.zip text.txt
adding: text.txt (stored 0%)

   That is, create a zip archive which does NOT preserve the VMS file
attributes. Then, when UnZip extracts the data in its default way, ...

alp $ unzip6l -d [.text] text.zip
Archive: ALP$DKC0:[SMS.itrc]text.zip;1
extracting: ALP$DKC0:[SMS.itrc.text]text.txt

alp $ write sys$output f$file_attributes( "[.text]text.txt", "RFM")
STMLF

alp $ diff text.txt [.text]text.txt
Number of difference sections found: 0
Number of difference records found: 0

DIFFERENCES /IGNORE=()/MERGED=1-
    ALP$DKC0:[SMS.itrc]text.txt;1-
    ALP$DKC0:[SMS.itrc.text]text.txt;1

   "zip -r" could make doing a whole tree pretty easy. Then all you
need to worry about is properly creating new content.

> Has anyone tried building 2.2 on Itanium?

Not I. My idea of a work-around in this case is to satisfy all
versions of the lameware, not to lock myself into some particular (old)
version of the lameware.

Neil Rieck · ‎10-08-2015

If you have a support contract, contact HP about the "stream_lf problem on CSWS-2.2-1" and they will quickly send you their patch. Mine works properly. I have no idea when they will make this fix generally available to the world.

Categories

Company

Local Language

Forums

Discussions

Forums

Discussions

Discussions

Forums

Discussions

Forums

Discussions

Discussions

Forums

Forums

Discussions

Forums

Discussions

Forums

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Discussion Boards

Community

Resources

Other HPE Sites

Discussions

Forums

Blogs

Apache / CSWS problems with Safari / Chrome / Opera

Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera

Re: Apache / CSWS problems with Safari / Chrome / Opera