Please be tolerant of this OT question and extensive OT reply ... there IS some Perl
in here.
On 05/03/00, ""Ranga Nathan" <[EMAIL PROTECTED]>" wrote:
> My web site is running on Apache/BSD and I would like to know how I can
> serve PNG files. When I try to view PNG files from my site in IE, it prompts
> me to download QuickTime. Currently I have converted all my PNG images to
> GIF. ...I was just wondering if there is a way to actually view PNG files in
> the browser....hmmm
Glad you asked! Thanks so much for supporting PNG by USING them! And don't let
yourself be swayed by anyone who says "Oh that's a waste of time, browsers don't
support PNG .." More and more that is a lot of ignorant misinformed hooey (rubbish
across the Atlantic etc. :-). For example, the new M$IE5/Mac has superb support for
PNG, the best that's yet been done in any mainstream browser client app. Opera 4beta
is compromised on its PNG support but its there. Etc.
OK, this is the problem (99% likelihood): your server (the httpd, Apache) has a
specific settings file named .mimetypes (I think) and that file is left as it was set
up "OOB" by many, many many server admins who are too hasty and pressured to pay
attention to the fact that *PNG is not in that file by default*. That's some thing
that the Apache people need to address.
One line, just one little line, needs to get added to this configuration file. it
looks like this:
image/png png
and then the httpd needs to be restarted so it will reads its configuration files
again.
Try that (try telling your admin about that). This is felt by many persons involved
with the PNG team to be a high-priority obstacle in the way of the much-needed
transition from GIF to PNG on the Net. it's not on the site authors nor on the browser
engineers but on the server admins and Apache (the core persons on the loose community
team that develops it) to get this one right. You look around and *many many* huge
servers (ISPs etc) with 10s and 100s thousands of users are cutting off the ability of
those users to inline PNGs in their Web pages simply through *ignorance and sloth*.
And they DO NOT RESPOND far too often when one tries to contact them. It can take some
persistance even with a more reasonable-size outfit. It's an obnoxious situation.
Try this Perl one liner (I promised some Perl and here is a start) to test for server
rectitude on MIME type):
==== NO WRAPPING WHATSOEVER ======
perl -MLWP -M"HTTP::Request" -e "$ua=LWP::UserAgent->new; $r=new
HTTP::Request('HEAD','http://SOMESERVER.TOPDOMAIN/cgi-bin/SOMEIMAGE.png');$rs=$ua->request($r);print
\"\n\". $r->as_string(). ' '.$rs->message .\"\n\";
@hdrs=%{($rs->headers)};$d=0;while($d<=$#hdrs){print \"$hdrs[$d++]: $hdrs[$d++]\n\"};"
==== FIX WRAPPING ON ABOVE LINES! ===
That (assuming you have pointed to a file that real exists on a real server -- upload
some .png if there isn't one there) will tell you whether Apache or any other http is
sane on PNGs.
Now for more Perl: there's a way to *subvert* the stinking status quo (at a cost of
server CPU cycles which admins who won't enable PNGs deserve to have to deal with) by
using Perl with LWP to serve PNGs as a call to a CGI instead of the normal path in an
inlined [IMG SRC= ] html call. I have a script that does this all ready for you.
It's at:
http://www.wonderstorm.com/techstuff/PerlTripod.html
I have named this Perl program "sbvrsn.pl" ("SUBVERSION").
Its Free Software copyright (c) ME (soren andersen) and made available under the gnu
copyleft (free modifiable, redistributable etc.) but if you use it I would appreciate
small note of attribution on your site.
The reason Tripod is in the html filename above is that Tripod is a free service that
offers CGI to its users but DOES NOT have its server (an Apache) correctly configured
for PNG. So being a big service they are representative.
A further note: It's funny you should ask, the last 2 weeks have seen a big discussion
of this issue over on the PNG List (PNG List <[EMAIL PROTECTED]>) -- please
subscribe to that list if you are interested in PNGs. One thing that's come to light
is that there is more to the M$IE case than meets the eye. YOUR M$IE behaved a certain
way when the server was wrong, but ANOTHER person's IE might have done something
different. Mine, for instance, will i think **OPEN THE BLOODY PNG in NETSCAPE** (!!)
if it is running, when the link to a PNG file is clicked. IE is using heuristics to
determine file type, and it shouldn't be -- it should stick to standards and BREAK
when the server is wrong, and so should all other browsers. But they don't and that's
because the teams that write the browsers at these big companies have been warped by
the problem of so many wrongly configured Web servers out there. Anyway with IE it
depends whether Windoze has a file association (local OS configuration) set up for PNG
or not. The browser is treating the data as an unknown data type and deciding what to
do on the basis of a complex heuristic.
There's also quite a bit more info on my site about how to use PNGs in certain Web
usages without breaking your presentation utterly for users of non-PNG-supporting
browsers. Etc.
HTH,
soren andersen
---
You are currently subscribed to perl-win32-users as: [archive@jab.org]
To unsubscribe, forward this message to
[EMAIL PROTECTED]
For non-automated Mailing List support, send email to
[EMAIL PROTECTED]
