in reply to Debugging without shell access?

I've fully tested this script on my own server. But its got to get deployed sometime and made to work on the production server.

I thought I was sending html headers with my heredoc "print <<EOF;" block. If that is not the case, then what am I missing, here?

This server is not of my choosing. My client's client contracts with them. They have an extensive bit of php code already there, working and bringing in revenue. I started out doing this in php, until I learned that their date fields were actually text fields and I switched to perl for Date::Manip so I could do date comparisons against these text fields.

-- Hugh

if( $lal && $lol ) { $life++; }

Replies are listed 'Best First'.
Re^2: Debugging without shell access?
by davorg (Chancellor) on Oct 30, 2006 at 16:27 UTC
    I thought I was sending html headers with my heredoc "print <<EOF;" block. If that is not the case, then what am I missing, here?

    You're missing the "Content-Type:" header.

    Update: Also, this is interesting:

    I've fully tested this script on my own server.

    How did you test it? Without the content-type header, there's no way it's going to work in a CGI environment.

    --
    <http://dave.org.uk>

    "The first rule of Perl club is you do not talk about Perl club."
    -- Chip Salzenberg

[reply]

      You're missing the "Content-Type:" header.

      ...

      Without the content-type header, there's no way it's going to work in a CGI environment.

      That's not entirely true. His code is perfectly valid ... for HTTP/0.9, running under some webservers. In fact, sending headers would be an error under HTTP/0.9. (current versions of Apache will strip them out for you, so you don't need to detect that case)

      I've just re-read the HTTP/1.1 specs, and I can't find any mention of Content-Type being required. The only 'MUST' that I see is for sending Content-Length on a request with a message body. (eg, POST). Even if that were not the case, all headers were optional in previous versions

      The following is a perfectly acceptable response, should you give it a useful message body:

      HTTP/1.0 200 OK

<html> ... </html>

      [download]

      The important factor is the blank line to seperate the headers from the body -- but personally, I'd just stick with using CGI or some other toolkit to generate the appropriate headers.

[reply]
[d/l]

        His code is perfectly valid ... for HTTP/0.9, running under some webservers.

        Except that the HTTP level has nothing at all to do with it. The CGI specification says that the Content-type, Location and Status are server directives; that is, they are used to communicate information back to the server. It's up to the server to create compliant HTTP messages. That's why you don't have to include a status line in your CGI program - the server will make sure there is one in the HTTP message.

        It's important to realize that CGI programs do not talk HTTP, they talk CGI. HTTP for communication between a browser and a web server, CGI is for communication between a web server and a back-end program. Granted, most headers are passed as-is into the HTTP message (this is a feature), but the content-type is first interpreted by the server.

        I've just re-read the HTTP/1.1 specs, and I can't find any mention of Content-Type being required.

        From the RFC: 

           Any HTTP/1.1 message containing an entity-body SHOULD include a
   Content-Type header field defining the media type of that body. If
   and only if the media type is not given by a Content-Type field, th
+e
   recipient MAY attempt to guess the media type via inspection of its
   content and/or the name extension(s) of the URI used to identify th
+e
   resource. If the media type remains unknown, the recipient SHOULD
   treat it as type "application/octet-stream".

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom