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.