HTML multipart form - maximum length of "boundary" string?

Question

In a multi-part (i.e. Content-Type=multipart/form-data) form, is there an upper limit on the length of the boundary string that an HTTP server should accept?

As far as I can tell, the relevant RFCs say 70 chars:

• RFC2616 (HTTP/1.1) section "3.7 Media Types" says that the allowed types in the Content-Type header is defined by RFC1590 (Media Type Registration Procedure).
• RFC1590 updates RFC-1521(MIME).
• RFC1521 says that a boundary "must be no longer than 70 characters, not counting the two leading hyphens".
• The same text also appears in RFC2046 which supposedly obsoletes RFC1521.

So can I be certain all the major HTTP/1.1 browsers out there today adhere to this limit? Are there any browsers (or other HTTP clients/libraries) known to break this limit?

Is there some other spec or common rule-of-thumb I'm missing that says the string will be shorter than 70 chars? In Chrome(ium) I get something like this: ----WebKitFormBoundaryLu4dNSGEhJZUgoe5, which is obviously shorter than 70 chars.

I'm asking this question because my server is running in an extremely memory-constrained environment, so "malloc a buffer large enough to hold the entire header string" is not an ideal answer.

Answer 1

As you note, RFC 2046 updated the MIME spec, but kept the restriction of the maximum boundary string to 70 characters, not counting the two leading hyphens.

I think it's a fair assumption that the spec is followed by all major browsers (and all MIME-using clients, like mail programs) since otherwise passing around multipart data would be very risky indeed.

To be sure, I've experimentally verified it for you using the latest versions of:

• curl: ----------------------------5a56a6c893f2 (40)
• Chrome 30 (WebKit): ----WebKitFormBoundarym0vCJKBpUYdCIWQG (38)
• Safari 6 (WebKit, and same as Chrome): ----WebKitFormBoundaryFHUXvJBZwO2JKkNa (38)
• FireFox 24: ---------------------------7096603861379320641089344535 (55)
• IE 10: ---------------------------7dd1961640278 (40) - same technique as curl!
• Apache HttpClient: -----------------------------1294919323195 (42)

Thus not only does every major browser/client conform, but all would allow you to save 15 allocated bytes per boundary per buffer from the theoretical max. If you could trivially switch on user agent, you could squeeze even more performance out. ;-)