in reply to Re: XML::Generator bad header?
in thread XML::Generator bad header?

I added what you suggested, here is the error I get when I try to load the XML file directly in the browser: 
XML Parsing Error: syntax error
Location: http://localhost/now.xml
Line Number 1, Column 1:Content-Type: text/xml
^

[download]
I am looking for a specific CGI XML header way of printing a header. Below is what the raw xml file looks like now. 
Content-Type: text/xml^M
^M

[download]
Trying this now 
print CGI->header('text/xml');
      
        print "<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n";

[download]
<edit> This didn't work either. 
XML Parsing Error: syntax error
Location: http://localhost/now.xml
Line Number 1, Column 1:Content-Type: text/xml
^

[download]
Content-Type: text/xml^M
^M
<?xml version="1.0" encoding="ISO-8859-1"?>

[download]

Replies are listed 'Best First'.
Re^3: XML::Generator bad header?
by Gangabass (Vicar) on Aug 19, 2007 at 01:07 UTC

    You are doing something wrong. Please show a little more piece of the code.

    Did you send any headers before 

    print CGI->header('text/xml');

    [download]

    ?
[reply]
[d/l]
      This is happens at the very end of the script. The only printing I do. 
      print CGI->header('text/xml');
print "<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>\n";
print "<dataset>\n";
print @output;
print "</dataset>";
exit;

      [download]
[reply]
[d/l]
        Then your webserver does some printing also
[reply]
Re^3: XML::Generator bad header?
by mr_mischief (Monsignor) on Aug 19, 2007 at 20:39 UTC
    You shouldn't be loading the file directly in the header with the Content-type: header as part of the file.

    The Content-type: header goes to STDOUT before any other output from your CGI program. It is followed by one blank line.

    After the Content-type: header is printed, your XML file's content can be sent to STDOUT from your CGI.

    The Content-type: header is never (or at least should never be) part of your actual XML file, so if you open the file directly in the browser, you should not have that as content.

    You can read more about the CGI specification at the NCSA, the W3C, or at the CGI section of CGI 1.1 co-author Ken Coar's web site, including info on issues with 1.1 and a draft for CGI 1.2 which may someday supersede it.
[reply]
I don't think you understand CGI still
by Anonymous Monk on Aug 21, 2007 at 11:52 UTC
    OK, lets take a step back here, you are getting confused between what CGI is, and what the file is.

    This is what a CGI application should return TO THE WEB SERVER.

    --------------------------------------------------
Content-type: text/plain (or text/html and so on)
Some-Other: headers
(a blank line)
The contents
of the file
goes here
--------------------------------------------------

    [download]

    So to send a text file the CGI prints this to STDOUT:

    --------------------------------------------------
Content-type: text/plain

Hello World!
--------------------------------------------------

    [download]

    ... and a HTML file

    --------------------------------------------------
Content-type: text/html

<html>
<body>
Hello World!
</body>
</html>
--------------------------------------------------

    [download]

    ... and an XML file

    --------------------------------------------------
Content-type: text/xml

<?xml version="1.0" encoding="ISO-8859-1"?>
<tag>Hello World!</tag>
--------------------------------------------------

    [download]

    I hope by now you see it's quite obvious you can't just spit the output of a CGI into a file and expect a browser to load that file, because you've incorrectly stuffed the extra headers into the file.

    It's no wonder the XML parser is freaking out.

    If you make a script that uses CGI.pm and adds the headers to the output, you can ONLY run it in a webserver.

    It's not useful for producing the file standalone any more.

    20070821 Janitored by Corion: Fixed stray </code> tag

[reply]
[d/l]
[select]
Re^3: XML::Generator bad header?
by Anonymous Monk on Feb 25, 2009 at 15:58 UTC

    I ran into a bit of a problem with this recently too. This is what I had. It worked, but, with warnings on, it threw a warning about using an undefined value in a le comparison.

    use CGI;
my $cgi = new CGI;
#...more stuff not important to this discussion
print $cgi->header( -type => 'application/xml');
print '<?xml version.......blah blah'."\n";

    [download]

    My browser seemed to know what to do with it just fine.

    In order to get around the warning, I stopped using the cgi header method. This is now what I do.

    use CGI;
my $cgi = new CGI;
#...more stuff not important to this discussion
print "Content-Type: application/xml\n".
      "\n".
      '<?xml version.......blah blah'."\n";

    [download]

    I found that I had to have exactly two \n characters after the Content-Type, before the "<?xml" part. Any more or less and the browser complained about not being able to parse the xml even though applications looking at the xml could handle it.

[reply]
[d/l]
[select]
      Please go back to using the CGI header method. If its giving you unwanted warnings (and you didn't enable global warnings, and you're not giving it undef values), then please update CGI
[reply]

In Section Seekers of Perl Wisdom