Re^4: Debugging without shell access?

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]

Comment on Re^4: Debugging without shell access? Download Code

Replies are listed 'Best First'.
Re^5: Debugging without shell access? by jhourcle (Prior) on Oct 31, 2006 at 16:04 UTC
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]

Replies are listed 'Best First'.

Re^5: Debugging without shell access?
by jhourcle (Prior) on Oct 31, 2006 at 16:04 UTC

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]