![]() |
Hello and Welcome from United States to the UNIX and Linux Forums! Thank You for Visiting and Joining Our Global Community.
|
|
google unix.com
|
|||||||
| Forums | Register | Forum Rules | Links | Albums | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| Shell Programming and Scripting Post questions about KSH, CSH, SH, BASH, PERL, PHP, SED, AWK and OTHER shell scripts and shell scripting languages here. |
More UNIX and Linux Forum Topics You Might Find Helpful
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Unix as fileserver | KBalquis | UNIX for Dummies Questions & Answers | 7 | 02-16-2007 05:43 PM |
| how to get cvs pserver work with xinetd | victorvvk | UNIX for Advanced & Expert Users | 1 | 05-27-2005 04:25 AM |
| uninstall xinetd | byblyk | Linux | 5 | 04-01-2004 02:39 PM |
| Fileserver?????????? with windows XP and unix | akari | IP Networking | 2 | 08-14-2002 12:00 PM |
| xinetd.conf | lealyz | Security | 2 | 01-21-2002 02:23 PM |
![]() |
|
|
LinkBack | Thread Tools | Search this Thread | Rate Thread | Display Modes |
|
|
|
||||
|
Fileserver in Perl via xinetd - bad XML output
Hello there,
I hope I took the right forum... I never worked with Perl, but now I have to get a simple fileserver running. The goal is to deliver an XML file (it's part of a new security model in the Flashplayer, see Adobe - Developer Center : Setting up a socket policy file server for more on that). Anyways, I can't get it to work properly. I took Adobe's script, which is intended to work with xinetd (the standalone script btw works fine, but I really want xinetd to handle this). After some small changes it seems to run fine now, but the Flashplayer complains about "malformed" XML. I changed the XML now a 1000 times, but it's always the same, and I begin to wonder, if maybe xinetd might be the problem? This is the XML: Code:
<?xml version="1.0"?> <cross-domain-policy> <site-control permitted-cross-domain-policies="master-only"/> <allow-access-from domain="mytld.com" to-ports="#####"/> </cross-domain-policy> Code:
#!/usr/bin/perl
#
# in.flashpolicyd.pl
# Simple socket policy file server
#
# Usage: in.flashpolicyd.pl -file=FILE
# Logs to stderr
#
use strict;
my $NULLBYTE = pack( 'c', 0 );
my $filePath;
my $content;
### READ ARGS
while ( my $arg = shift @ARGV )
{
if ( $arg =~ m/^--file=(.*)/ )
{
$filePath = $1;
}
}
unless ( $filePath )
{
die "Usage: in.flashpolicyd.pl --file=FILE\n";
}
### READ FILE
-f $filePath or die "No such file: '$filePath'\n";
-s $filePath < 10_000 or die "File probably too large to be a policy file: '$filePath'\n";
{
local $/ = undef;
open POLICYFILE, "<$filePath" or die "Can't open '$filePath': $!\n";
$content = <POLICYFILE>;
close POLICYFILE;
}
$content =~ m/cross-domain-policy/ or die "Not a valid policy file: '$filePath'\n";
### HANDLE CONNECTIONS
local $/ = $NULLBYTE;
my $request = <STDIN>;
chomp $request;
if ( $request eq '<policy-file-request/>' )
{
print STDERR "Valid request received\n";
}
else
{
print STDERR "Unrecognized request: $request\n\n";
exit;
}
print STDOUT $content;
#print STDOUT '<?xml version="1.0"?><cross-domain-policy><site-control permitted-cross-domain-policies="master-only"/><allow-access-from domain="mytld.com" to-ports="#####"/></cross-domain-policy>';
print STDERR "Sent policy file\n\n";
# End of file.
So, is it possible that xinetd adds something to the result? Or does anyone sees another thing that might be wrong? I'm fighting with this for 2 days now, so any help is very appreciated. cheers |
|
||||
|
Have you used a packet sniffer to ensure that the bytestream returned is exactly as expected? Also, the XML you returned as string, you are sure it is valid?
Last, try force auto flush and see if that helps (put it at the beginning of the script): Code:
$| = 1; |
|
||||
|
Hi,
no, I didn't use a packetsniffer (yet). I also tried the auto flush, but it made no difference. The XML has to be valid, because when I run the standalone script (also from Adobe) with the same XML file, it all works fine. The scripts, standalone and xinetd service, are basically the same, except that the standalone handles all the socket stuff itself, where the xinetd service script just reads from STDIN and writes to STDOUT. The other parts (handling the rquest, reading the file) are identical. That's why I'm pretty sure now that it has something to do with the xinetd. Maybe I'll try a packetsniffer when I have some spare time. Meanwhile I use the standalone daemon and have a cron job watching over it. One more service constantly running... well, if Adobe thinks this is safer than an XML served by my webserver... sigh. |
|
||||
|
Quote:
So, what I have is Code:
open POLICYFILE, "<$filePath" or die "Can't open '$filePath': $!\n"; $content = <POLICYFILE>; close POLICYFILE; ... print CONNSOCK $content; print CONNSOCK $NULLBYTE; close CONNSOCK; Code:
open POLICYFILE, "<$filePath" or die "Can't open '$filePath': $!\n"; $content = <POLICYFILE>; close POLICYFILE; ... print STDOUT $content; I guess that xinetd is supposed to push the output into the socket and add the terminating NULL byte. I don't know how xinetd works, but I've read that you just have to give your output into STDOUT when you're doing a xinetd service, so I guess this is the way to do it. However what xinetd does after that is beyond me. |
|
||||
|
Then you should use it now. As you have a static version that works but a version served from Perl does not, that makes a good control experiment to find out what is the difference. Make sure the XML used is identical in both cases.
Wireshark is a good sniffer. |
![]() |
| Bookmarks |
| Tags |
| perl, perl shift, shift, shift perl |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|