3

My reading of RFC 2616 hasn't answered my question:

How should a server interpret multiple Accept, Accept-Encoding, Accept-Language, etc, headers?

Granted, this should generally be a rare occurrence, but far be it from me to assume every HTTP client actually does what it should.

Imagine an HTTP request includes the following:

Accept-Language: en
Accept-Language: pt

Should the server:

  1. Combine the results, to an effective Accept-Language: en, pt?
  2. Honor only the first one (en)?
  3. Honor only the last one (pt)?
  4. Throw a hissy fit (return a 400 status, perhaps?)

Option #1 seems the most natural to me, and the most likely to be what the client means, and the least likely to completely break expectations even if it's not what the client means.

But is there any actual rule (ideally specified by an RFC) for how to handle these situations?

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189

1 Answers1

6

1) You are looking at an outdated RFC. RFC 2616 has been obsoleted two years ago.

2) That said, the answer is 1); see https://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.3.2.2.p.3: "A recipient MAY combine multiple header fields with the same field name into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. (...)"

Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
  • Let's also add that this is not true for all headers. Content-Length header for example has to be unique. – regilero Oct 07 '16 at 12:49
  • It is true in that a recipient is allowed to comma-recombine them. It just means that the garbage was sent, and was transformed into a different kind of garbage. – Julian Reschke Oct 07 '16 at 14:00