in reply to Love/Hate Internet Explorer

This is so much like the recent discussion at Larry vs. Joel vs. Ovid -- in this case, the HTTPD protocol has a well defined format in that the first line sent over the connection is a content type line, and some followup lines that may or may not include details like cookies, content length, etc. But this is all a standard, with only a few small changed (additional fields that could be accepted) since it's release. Yet, Microsoft in their incredible wisdom, is trying too accept too much and refuse little. Your example is one problem; another that I know others have had is that they want to send a HTML document as a text file as an example of code to use; that is, the end file should include all tags and the like. It's possible to force the Content-Text to plain/text on nearly any other browser, but there is absolutely no way to do this in IE; the file will always be rendered as HTML.

Now, I'm wondering if there's a reasonable solution that we can at least do with perl and CGI.pm; that is, when you create a new CGI object, there should be a flag that is set when header() is called. If the object is destroyed while this flag is unset, then a warning/die() should be issued that a header was not sent, and there *may* be erroneous code around (lacking a header line). Obviously, I'd opt to have this as an option that must be set to work, as opposed to a default out of the box. And it's certainly not infallable: this code will not trigger the warning despite header() being called: 

my $q = new CGI;
$q->header( 'plain/text' );  # It's not being printed!

[download]

(Actually, thinkning about it, I'd figure it would be just as easy to create a class such as CGI::HeaderHunter, which acts like a CGI object, but incorporates a "header()" override function and provides a new DESTROY call. Instead of creating a CGI object, you'd create this one. Not quite sure on the details yet, of course...)

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

Replies are listed 'Best First'.
(Ovid) Re: Re: Love/Hate Internet Explorer
by Ovid (Cardinal) on Nov 30, 2001 at 04:04 UTC

    Masem wrote:

    ...the HTTPD protocol has a well defined format in that the first line sent over the connection is a content type line, and some followup lines that may or may not include details like cookies, content length, etc...

    That's not quite accurate. The first line of the server's response is typically a status line such as HTTP/1.1 200 OK. Subsequent headers may be general headers (e.g. Date:...), response headers (e.g. Location:...), or entity headers (e.g. Content-type:...). These header types may be specified in any order, so long as there is at least one blank line separates the headers and the entity-body.

    Section 6.1 of RFC2616 specifies that the first line of the response must be the status line. Again, subsequent lines can be sent in an arbitrary order. Interestingly, the protocol makes clear that headers end with two CRLFs ("\r\n"), but most clients issue a "\n\n" instead, but all browsers (that I've run across) interpret this correctly. Is this a case of most Web servers catching and correcting for this, or most browsers being smart enough to handle this? I suspect the former.

           Response      = Status-Line               ; Section 6.1
                       *(( general-header        ; Section 4.5
                        | response-header        ; Section 6.2
                        | entity-header ) CRLF)  ; Section 7.1
                       CRLF
                       [ message-body ]          ; Section 7.2

    [download]

    Cheers,
    Ovid

    Update: D'oh! Fastolfe is right. I should have said "CGI script" instead of client.

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]
[d/l]

      Is this a case of most Web servers catching and correcting for this, or most browsers being smart enough to handle this? I suspect the former.

      And you'd be right. It pays occasionally to remember that CGI/1.x != HTTP/1.x. The data protocol a CGI script uses to send data to the web server may look like HTTP, but it's CGI. The web server should parse the script's output per the CGI specification, not HTTP, and then issue to the browser a properly-formatted HTTP response.

      The real question is: Does the CGI specification mandate any specific style of newline? Beats me, but the web server (Apache in my case) seems to like any type of newline I give it.

      It always generates HTTP newlines as \cM\cJ, though.

[reply]
[d/l]
[select]

In Section Meditations