WASD GZIP / ZLIB

[Wim Van den Wyngaert]

I installed WASD9.0.1 with ZLIB 1-2-2-EV56.
I start the HTTP server and check with TCPTRACE if a page contents is readable : I don't find any info in the trace that reminds me on the page I was loading, so it must be encrypted. So, it works.

But when I load a page that takes about 5 seconds to load (heavy processing behind it), I get the message "done" in the browser together with a blank screen. The HTTP process on VMS level didn't die.

My config says :
[GzipResponse] 9
[GzipAccept] 1

And my modif to the default (as far as I remember):
[CgiStrictOutput] enabled

Anyone an idea why ?

Wim

[Wim Van den Wyngaert]

This was the html generated by the server.



<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

[Wim Van den Wyngaert]

Restarted the whole stuff, cleared IE cash, rebooted PC and now same effect, the html code contains something different :

MRX



• 
  
  It seems that some info was lost.
  
  I tried the same with Mozilla on VMS. HTML is still incomplete but most of the time (of course not always) there is a result but the title is missing ...
  
  Wim

[labadie_1]

You should use the marvelous Watch to debug

http://wasd.vsm.com.au/ht_root/doc/htd/
the beginning of the doc

20 - WATCH Facility

20.1 - Server Instances
20.2 - Event Categories
20.3 - Request Filtering
20.4 - Report Format
20.5 - Usage Suggestions
20.6 - Command-Line Use


The WATCH facility is a powerful adjunct in server administration. From the Server Administration facility (19 - Server Administration) it provides an online, real-time, in-browser-window view of request processing in the running server. The ability to observe live request processing on an ad hoc basis, without changing server configuration or shutting-down/restarting the server process, makes this facility a great configuration and problem resolution tool. It allows (amongst other uses)


assessment of mapping rules
assessment of authorization rules
investigation of request processing problems
observation of script interaction
general observation of server behaviour

[Wim Van den Wyngaert]

Labadie,

I already did. I asked the complete trace (2 first columns flagged in WATCH).
Here is the result in attachment.

I changed the zip level from 9 to 1. Idem.


Wim

[Wim Van den Wyngaert]

And in attachment the HTML code received in IE.

Wim

[Antoniov.]

Wim,
your font size is too small. Size 2 of fonts is not readable by any browser. The littest size readable is 8.

Antonio Vigliotti

[Wim Van den Wyngaert]

Antonio,

Book an airplane and come and watch. It is perfectly readable on a 21 inch as well as on a 15 inch screen.

Wim

[Wim Van den Wyngaert]

All,

If checked the script that generates the stuff.

The first lines it generates when the output is shown correctly is :
Content-type: text/HTML



<meta http-equiv="REFRESH" content="120" />

And in the HTML of IE I see
<meta h="" />Report of consolidated VER_PROC loggings

Truncated but by accident working ?


When it doesn't generate the META line (depends on the parameters) I goes wrong. I get

[Antoniov.]

Wim,
I should be happy to come and watch that, if you would have airplane ticket on you! I promise I'll pay for all beers we drink ;-)

Wish you Happy New Year
Antonio Vigliotti

[Mark Daniel_2 · Accepted solution]

I believe I have seen similar behaviour recently myself though unlike your instance it appears not be consistently reproducable (happy-happy, joy-joy). Using ZLIB in an AST-driven context has proved problematic on a previous occasion (during BETA testing). I can easily imagine I have still not got it 100% water-tight even with considerable testing and general usage. I am currently in the process of looking at the code again (having only just returned from time away from all of these small pleasures :-)

You have investigated and reported it quite thoroughly Wim (thanks for using WATCH), so so I don't doubt the veracity of your report.

First try getting the script to request the server not to chunk the response. Add the following to your script's CGI response header:

Content-Type: text/html
Script-Control: X-transfer-encoding-chunked=0

(the last is all one line just in case it wraps - this ITRC forums interface is awful)

Then see if the behaviour persists. My guess is it will. Then try suppressing the GZIP encoding:

Content-Type: text/html
Script-Control: X-transfer-encoding-chunked=0
Script-Control: X-content-encoding-gzip=0

Again my guess is that the problem will vanish (along with the compression). You can then turn chunking back on by removing the appropriate header or changing it to:

Content-Type: text/html
Script-Control: X-transfer-encoding-chunked=1
Script-Control: X-content-encoding-gzip=0

This will isolate the problem functionality.

You might also request that the server buffers the records your script is sending before providing them to the network (and GZIP encoding). The following will do that and have GZIP encoding switched back on:

Content-Type: text/html
Script-Control: X-buffer-records=1
Script-Control: X-transfer-encoding-chunked=1
Script-Control: X-content-encoding-gzip=1

My reason for suggesting we try this is to help establish whether it's the sizes of the data 'chunks' being given to the GZIP code that's contributing to the problem. Buffering records will cause a consolidated block of multiple records, rather than individual records, to be given to the GZIP encoding, probably changing the behaviour.

Leaving [GzipResponse] at zero will allow you to continue development until the issue is resolved (at the small sacrifice of no response compression).

This forum's interface is pretty clunky so shall we pursue this outside ITRC and we can report back when it's resolved?

I'd also recommend the info-WASD mailing list for these types of issues, it's a little less VMS-general/more WASD-specific.

[Wim Van den Wyngaert]

100% right. The suggestions work.

Wim

[Wim Van den Wyngaert]

The problem will be solved in 9.0.2 or whatever comes next.

Thanks Mark.

Wim