Gulp!
I guess the CERN server ignored my "Content type: text/html\n\n" header.
Note the missing "dash" should be "Content-type: text/html\n\n".
That's the first thing I tell people to check... 
Thanks Matt!

-Bob Cozzi
www.RPGxTools.com
RPG xTools - Enjoy programming again.


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Matt.Haas@xxxxxxxxxxx
Sent: Wednesday, January 25, 2006 1:19 PM
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Apache EBCDIC to ASCII issue

What happens if you call the counter program directly? I know this works
because I call CGI's via SSI's all the time. Also, are you 100% sure the
HTTP headers are correct?

Matt 

-----Original Message-----
From: web400-bounces+matt.haas=thomson.com@xxxxxxxxxxxx
[mailto:web400-bounces+matt.haas=thomson.com@xxxxxxxxxxxx] On Behalf Of
Bob Cozzi
Sent: Wednesday, January 25, 2006 2:12 PM
To: 'Web Enabling the AS400 / iSeries'
Subject: Re: [WEB400] Apache EBCDIC to ASCII issue

Nope. Didn't help. Hmmm??

-Bob Cozzi
www.RPGxTools.com
RPG xTools - Enjoy programming again.


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On
Behalf Of Matt.Haas@xxxxxxxxxxx
Sent: Wednesday, January 25, 2006 12:52 PM
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Apache EBCDIC to ASCII issue

Bob,

If you have CGIConvMode in your configuration, take it out. I vaguely
recall this being a problem for everyone who had it specified over at
Ignite/400.org when Apache first came out.

Also, if you happened to run the migration wizard/configuration mangler,
be prepared to have some fun with the crap it generates. I tried it on a
bunch of different server configurations and the only ones that even
worked were trivial (trivial to the point where just running the new
server wizard got you 95% of the functionality). In the end, I ran the
new server wizard for each of the instances I migrated and built them
out by hand. Besides actually working, the hand built ones also
performed better.

Matt 

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Bob Cozzi
Sent: Wednesday, January 25, 2006 1:29 PM
To: 'Web Enabling the AS400 / iSeries'
Subject: [WEB400] Apache EBCDIC to ASCII issue

If I write directly from a SSI (CGI) program to QtmhWrStout, the server
seems to avoid doing the EBCDIC to ASCII conversion on the generated
HTML.

For example, I have a SSI that writes an HTML comment to the page with
the
number of visits to that particular page from your IP address.

On the old CERN server, there was no issue. Moving to Apache on V5R3,
this
particular SSI which writes to stdout using QtmhWrStout directly seems
to be
avoiding converting the data I'm sending to the browser. That is, it is
sending EBCDIC instead of ASCII. Hence I get a bunch of crap in the
browser.

Yet, if I use CGILIB (my version of a CGIDEV2-style library) and send a
huge
chunk of HTML (like my weekly surveys) everything is output correctly.
Ironically those interfaces also use QtmhWrStout.

I actually tested this by going into the visits counter program and
converting the data to CCSID(819) and then writing it via QtmhWrStout.
It
worked perfectly.

Yet no such conversion is performed in CGILIB as it lets the server
handle
conversions automagically, and there is never a problem.

I do see conflicting things in the midrange-l archives and on the
IBM.com
website with respect to CGIConvMode  %%EBCDIC/EBCDIC%% vs
%%MIXED/MIXED%%.

But I thought that was only used for encoding URL strings read by CGI
programs, not for writing data to the stdout.

Anyone else run into this kind of issue?

 

-Bob Cozzi

www.RPGxTools.com

RPG xTools - Enjoy programming again.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.