4

Quick question - is there a maximum size for the Status-Line of a HTTP Response?

In the RFC I could not find this information, just something like this:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

According to this i could assume:

  • HTTP-Version is usually 8 Bytes ( e.g. HTTP/1.1 )
  • Status-Code is 3 Bytes
  • 2 Spaces + CRLF is 4 Bytes
  • Reason-Phrase -> The longest according to the RFC is Requested range not satisfiable so 31 Bytes

This would be a sum of 46 Bytes.

Is this assumption correct or did I miss anything?

UPDATE:

Due to the answer below, I just want to specify my problem a bit:

I am parsing some kind of Log file with TCP messages from a server. Now there is some random Data I don't care for and some HTTP Messages which I want to read. Now all data I get I parse for a \r\n to find the Status Line. Since I need to make assumption that my header is split into several TCP packages I just buffer all data and parse it.

If there is no maximum size for the header status-line, I need to buffer all data until the next \r\n occurs. In the worst case this means I save like kilobytes over kilobytes of random data, since it could ( but will most likely will not ) be part of the Header Status Line.

Or would it , in this case, be rather appropriate to parse for the HTTP Version String instead of the CRLF ?

Toby
  • 3,815
  • 14
  • 51
  • 67
  • Since the line is terminated by a newline, it could in theory be infinite. The same goes for all other lines in the request/response headers as well. – Some programmer dude Mar 01 '12 at 09:24

2 Answers2

4

RFC 2616, 6.1.1:

The reason phrases listed here are only recommendations -- they MAY be replaced by local equivalents without affecting the protocol.

Aside from this, the HTTP protocol is "allowed" to add more status codes (in a new RFC) without changing the HTTP version to 1.2, provided that the new codes don't introduce additional requirements on HTTP clients. Clients are supposed to treat an unknown status code as if it were x00 (where x is the first digit of the code they get, indicating the category of response), except that they shouldn't cache the response.

So the only limit is the max length of an HTTP header line or of the response headers in total. As far as I can see, the RFC doesn't define any limit, although specific servers impose their own.

What you can be sure of is that the user-agent may ignore the Reason Phrase entirely. So if it's big, you can read it in small pieces and throw them away one at a time until you reach CRLF. If you want to display a human-readable message, mostly you can use the recommended Reason Phrase for the status code that the server provides, regardless of what Reason Phrase the server sends.

Steve Jessop
  • 273,490
  • 39
  • 460
  • 699
  • Thanks for you answer - I specified my question a bit more to make my problem a bit more precise! – Toby Mar 01 '12 at 09:37
  • @Toby: given your update I'd say yes, check for the HTTP version string first to make sure you have an HTTP response. If it's there, look at the rest of the HTTP response (and although in theory there could be kb of reason phrase, in practice there will not be since these messages are all from a real server that presumably behaves fairly sanely, not from a theoretical server that sends its Reason Phrases as 24fps ASCII art depicting the problem in the form of interpretative dance). If it's not there move on. – Steve Jessop Mar 01 '12 at 09:42
  • Okay, so this means I can at least assume that the HTTP Header Status Line will always begin with HTTP/X.X ..? – Toby Mar 01 '12 at 09:45
  • @Toby: Well, your server could eventually support a future version of HTTP, so each "X" could be multiple digits. But then you'd need to update some code somewhere anyway, in order to understand the response headers of this new HTTP version. Until that happens, an HTTP response will begin either "HTTP/1.0" or "HTTP/1.1". – Steve Jessop Mar 01 '12 at 10:18
0

I don't think there is any limit on the length of the ReasonPHrase. The W3C doc states it is a "short message" but that is not canonical.

I would not assume Version is 8 characters. Perhaps a version in the future could have 3 digits, ie: HTTP/10.1. The syntax specifies Version is delimited by a SPACE, so I would parse it by stopping at the first SPACE.

https://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html

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.

Beans
  • 1,159
  • 7
  • 17