Setting the "href" in a stylesheet link to an executable script?

[Dave Hammond]

I recently noticed the stylesheet link in an html page had the href set
to a PHP script, as in:

<LINK REL="stylesheet" href="some_css.php" type="text/css">

Presumably the file being referenced was actually an executable PHP
script and not a css file that happened to have a .php extension.
Based on that assumption, I tried the same thing with a Perl script
(the webserver being tested happens to have mod_perl installed but not
mod_php), as in:

<LINK REL="stylesheet" href="dyn_css.pl" type="text/css">

The result was a server error with the error_log entry:

Bareword found where operator expected at
/srv/www/plwa/test/dyn_css.html line 4, near ""dyn_css.pl" type"
(Missing operator before type?)

The Perl script returns a simple stylesheet object...

body {
background-color: #000000;
font-family: Verdana;
font-size: 10px;
color: #FFFFFF;
border: 5px solid #AAAAAA;
}

.... which is exactly what the aforementioned PHP script returned when
retrieved by wget.

So, the question is: can an executable script be referenced in a
stylesheet link? If so, can anyome comment on why I might be getting
the above error from the server?

O/S: SuSE Linux 8.x
Server: Apache 2.x with mod_perl (.pl files associated with the
perl-script handler using an AddHandler statement).

Thanks!
--
Dave H.

[Stian Lund]

"Dave Hammond" <dh****@gmail.com> wrote in news:1126876909.069914.315680
@f14g2000cwb.googlegroups.com:

So, the question is: can an executable script be referenced in a
stylesheet link? If so, can anyome comment on why I might be getting
the above error from the server?

This is quite interesting if it can be done ... have you looked into what
content-type the server is returning for the php file? Use wget to get the
headers returned (wget -S). Most likely they have set the content-type to
text/css and not text/html which is usual for php scripts.

In PHP you would change the header something like this:
header("Content-Type: text/css")
before any content is output to the client.

It might be what they are doing.

Stian

[Dave Hammond]

A good hypothesis, but according to wget -S the type being returned is
text/html:

HTTP request sent, awaiting response...
1 HTTP/1.1 200 OK
2 Date: Fri, 16 Sep 2005 12:45:45 GMT
3 Server: Apache/2.0.46 (Red Hat)
4 Accept-Ranges: bytes
5 X-Powered-By: PHP/4.3.2
6 Connection: close
7 Content-Type: text/html; charset=UTF-8

[ <=> ] 867 846.68K/s
10:55:29 (846.68 KB/s) - `gp_css.php' saved [867]

--
Dave H.

[Jim Moe]

Dave Hammond wrote:

<LINK REL="stylesheet" href="dyn_css.pl" type="text/css">

The result was a server error with the error_log entry:

Bareword found where operator expected at
/srv/www/plwa/test/dyn_css.html line 4, near ""dyn_css.pl" type"
(Missing operator before type?)

Is your server configured to run perl on files that have the extension
"pl"?
--
jmm dash list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

[Sherm Pendley]

Jim Moe <jm***************@sohnen-moe.com> writes:

Dave Hammond wrote:

<LINK REL="stylesheet" href="dyn_css.pl" type="text/css">
The result was a server error with the error_log entry:
Bareword found where operator expected at
/srv/www/plwa/test/dyn_css.html line 4, near ""dyn_css.pl" type"
(Missing operator before type?)

Is your server configured to run perl on files that have the
extension "pl"?

It obviously is, given that the above error is a Perl syntax error. ;-)

sherm--

--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org

[Dave Hammond]

I thought that "bareword" phrase looked familiar ;-)

Of course, now the question is why, when run from the apache mod_perl
handler, does it generate the syntax error? Here's the script in
question:

# cat dyn_css.pl
#!/usr/bin/perl

print <<EOFEOF;
Content-type: text/html

body {
background-color: #000000;
font-family: Verdana;
font-size: 10px;
color: #FFFFFF;
border: 5px solid #AAAAAA;
}
EOFEOF

Not exactly brain surgery :) And, of course it passes perl -cw syntax
checking and runs just fine from the command line. So, why does it
generate the error?

-Dave H.

[Jim Moe]

Dave Hammond wrote:

print <<EOFEOF;
Content-type: text/html

body {

Not exactly brain surgery :) And, of course it passes perl -cw syntax
checking and runs just fine from the command line. So, why does it
generate the error?

HTTP expects <CR><LF>, not just <LF>. If you are serving from a *nix
system, perhaps it is just sending a simple newline (<LF>) as a linebreak?

--
jmm dash list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

[Dave Hammond]

This is a re-post... not sure why it didn't show up the first time
around. Please ignore this if it ends up to be a dupe...

I should have realized that the "Bareword found" error looked familiar.
Of course, now the question is why is Perl complaining. The script is
trivial; it passes the Perl -cw syntax check and outputs the expected
text. Here is the source:

#!/usr/bin/perl

print <<EOFEOF;
Content-type: text/html

body {
background-color: #000000;
font-family: Verdana;
font-size: 10px;
color: #FFFFFF;
border: 5px solid #AAAAAA;
}
EOFEOF

This seems to prove that Apache is attempting to call Perl, although
exactly how is not clear. Is there any way to log the syntax of the
call that Apache is making to Perl?

-Dave H.

[Alan J. Flavell]

On Mon, 19 Sep 2005, Jim Moe wrote:

Dave Hammond wrote:

print <<EOFEOF;
Content-type: text/html
The content looks more like text/css to me!!!
body {

Not exactly brain surgery :) And, of course it passes perl -cw syntax
checking and runs just fine from the command line. So, why does it
generate the error?
HTTP expects <CR><LF>, not just <LF>.

I thought this was meant to be a CGI script? As such it's entitled to use
its local newline convention. It's the job of the web server to turn
valid parsed-headers CGI output (per the CGI RFC) into valid HTTP protocol
(per the HTTP RFC, 2616), and that includes newlines conversion as
necessary.
If you are serving from a *nix system,
perhaps it is just sending a simple newline (<LF>) as a linebreak?

Very likely, but unless it's a no-parse-headers script (which it isn't
going to be unless the O.P has gone to special effort to make it so) then
that should be no problem.

But I don't look any more closely at Perl scripts until they've been
properly tested per the posting guidelines of comp.lang.perl.misc.

[Andreas Prilop]

On 19 Sep 2005, Dave Hammond wrote:

Organization: http://groups.google.com
User-Agent: G2/0.2
The innocents abroad.
body {
font-family: Verdana;
font-size: 10px;

DO NOT specify a body font-size - not in px anyway!

--
Top-posting.
What's the most irritating thing on Usenet?

[Dave Hammond]

Guys, IMO, we're getting away from the actual problem, which has
already been pointed out by Sherm Pendley: It is *perl* complaining in
the error message, not the web server.

As for the perl code itself, any first year perl programmer can see
that this trivial little script is absolutely valid and functional,
regardless of not meeting the posting guidelines of
comp.lang.perl.misc... so let's not get stuck on that.

It appears that the server is invoking perl and passing it the entire
<LINK ...> statement, rather than just the name of the perl script to
be run. That would account for the "bareword" error:

Bareword found where operator expected at
/srv/www/plwa/test/dyn_css.html line 4, near ""dyn_css.pl" type"
(Missing operator before type?)

I think this behaviour indicates that the server is in some way being
confused by naming a perl script in the link href. So, maybe we can
get back to the original question and avoid any potentially unnecessary
head banging:

Does anyone have experience or reference to whether or not you can
invoke a perl or php script as the href in a stylesheet link statement?

Thanks!

-Dave H.

[Dave Hammond]

Problem resolved and original question answered!

At least with respect to Apache 2, a CGI script can absolutely be named
as the href in a stylesheet link. This provides a nice mechanism for
dynamically modifying a page style.

The "bareword" problem had to do with mis-use of a perl handler within
a <Location> object in the Apache configuration.

Thanks to all who responded.

-Dave H.

[Alan J. Flavell]

On Tue, 20 Sep 2005, Andreas Prilop wrote:

On 19 Sep 2005, Dave Hammond wrote:

body {
font-family: Verdana;
font-size: 10px;

DO NOT specify a body font-size - not in px anyway!

That's not the whole problem with the above...

http://www.xs4all.nl/~sbpoley/webmatters/verdana.html

Verdana is a perfectly fine font, *for appropriate purposes*, but
*not* good to be specified by web authors. Poley gives the best
explanation and demonstration that I've seen. The other articles on
that site are a good read too.

cheers