A normal HTTP response looks like:
HTTP/1.0 200 OK
Is it OK to omit what the RFC calls the Reason-Phrase? Something like:
HTTP/1.0 200
The RFC says:
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
Reason-Phrase = *<TEXT, excluding CR, LF>
I understand this as:
So the following would be valid:
HTTP-Version SP Status-Code SP CRLF
Do I understand the RFC correctly?
The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason- Phrase.
An HTTP response contains: A status line. A series of HTTP headers, or header fields. A message body, which is usually needed.
HTTP Response broadly has 3 main components: Status Line. Headers. Body (Optional)
After receiving and interpreting a request message, a server responds with an HTTP response message: A Status-line. Zero or more header (General|Response|Entity) fields followed by CRLF. An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields.
It looks that way, if you read the *
as 'zero or more characters', like in regular expressions.
It seems to have a slightly different meaning if you read the Notational Convention of the RFC:
*rule
The character "*" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and at most <m> occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero; "1*element" requires at least one; and "1*2element" allows one or two.
So although it's not regex, the meaning is essentially the same. The asterix, not having a trailing number in this case, means that there can be "0 or more" "texts". Odd way to put it, but it seems you're right.
Strictly speaking, the space is mandatory, although I'd think a separator might be omitted if there's nothing to separate. It might kill clients that have a strict implementation, though, if they just split this string on the spaces and try to read the element in which the description should be. But then again, those clients should have used some defensive programming to catch that situation. ;)
The RFC does say that it can be any text, as long as it is a human readable description of the problem. This text is important, because the client may not understand the exact meaning of the status code, so it may need to display the text to the user. So even though you can omit it, I personally wouldn't.
The Reason-Phrase is indeed optional. In fact, HTTP/2 even dropped it entirely:
HTTP/2 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With