in reply to Re^2: Debugging without shell access?
in thread Debugging without shell access?

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.

Replies are listed 'Best First'.
Re^4: Debugging without shell access?
by Anonymous Monk on Oct 31, 2006 at 09:53 UTC

    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]
      It's important to realize that CGI programs do not talk HTTP, they talk CGI.

      Again, that's not always true. The specific secton of the CGI specifications that you're trying to cite is labeled Parsed Headers, which is a certain type of CGIs (although, they are the most prevalent type of CGIs these days, and many folks aren't aware of the alternatives). NPH CGIs are expected to return valid HTTP (see the section 'Script Naming Conventions' on that same page).

      The point that I'm trying to make that these are not absolutes -- the HTTP/CGI/HTML specs are relatively lax, and there is plenty of leeway on implementation. (and I'm not trying to say this is a good thing, either -- although it made adoption easier, it has made it much more difficult to achieve consistent results across browser implementations)

      In the recommendation made to fix the problem, the issue wasn't the lack of a Content-Type header, it was the lack of any header. So although adding a Content-Type header fixed the problem, it's important to realize that having added any header would have fixed the symptoms that were described. (assuming that was the only issue, which apparently it wasn't)

      Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header

      As I said -- not required. As specified in RFC 2119:

      3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

      If it were required, it would say MUST, REQUIRED or SHALL. Unfortunately, there are some older browsers which will look at the file's extension, and try to determine file type from that. (some would even prefer the extension over the Content-Type sent). Most servers running in parsed header mode will insert a Content-Type if there isn't one there, but many (Apache included) default to text/plain rather than text/html.

[reply]

In Section Seekers of Perl Wisdom