6

There're many ways to write an HTTP-status header:

HTTP/1.1 404 Not Found
Status: 404
Status: 404 Not Found

but which is the semantically-correct and spec-compliant way?

Edit: By status headers I mean this, using a function such as PHP's header().

moo
  • 7,619
  • 9
  • 42
  • 40

4 Answers4

4

Adding some information some time later, since I came across this question whilst researching something related.

I believe the Status header field was originally invented as part of the CGI specification, RFC 3875:

https://www.rfc-editor.org/rfc/rfc3875#section-6.3.3

To quote:

The Status header field contains a 3-digit integer result code that
indicates the level of success of the script's attempt to handle the
request.

   Status         = "Status:" status-code SP reason-phrase NL
   status-code    = "200" | "302" | "400" | "501" | extension-code
   extension-code = 3digit
   reason-phrase  = *TEXT

It allows a CGI script to return a status code to the web server that overrides the default seen in the HTTP status line. Usually the server buffers the result from the script and emits a new header for the client. This one is a valid HTTP header which starts with an amended HTTP status line and omits the scripts "Status:" header field (plus some other transformations mandated by the RFC).

So all of your examples are valid from a CGI script, but only the first is really valid in a HTTP header. The latter two are only valid coming from a CGI script (or perhaps a FastCGI application).

A CGI script can also operate in "non-parsed header" (NPH) mode, when it generates a complete and valid HTTP header which the web server passes to the client verbatim. As such this shouldn't include a Status: header field.

Note, what I am interested in is what which status should win if an NPH script gets it a bit wrong and emits the Status: header field, possibly in addition to the HTTP status line. I can't find any clear indication so and I suspect it is left to the implementation of whatever is parsing the output, either the client or the server.

Community
  • 1
  • 1
wu-lee
  • 749
  • 4
  • 17
3

Since https://www.rfc-editor.org/rfc/rfc2616#section-6 and more specifically https://www.rfc-editor.org/rfc/rfc2616#section-6.1 does not mention use of "Status:" when indicating a status code, and since the official list of headers at http://www.iana.org/assignments/message-headers/message-headers.xml does not mention "Status", I'd be inclined to believe it should not be served with it as a header.

Community
  • 1
  • 1
Brett Zamir
  • 14,034
  • 6
  • 54
  • 77
1

The closest thing I've found to an answer is the Fast CGI spec, which states to set status codes through Status and Location headers.

moo
  • 7,619
  • 9
  • 42
  • 40
0

A lot of them are pretty much arbitrary strings, but there here is the w3c's spec for the commonly used ones

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Jason Watts
  • 1,086
  • 5
  • 13