Allow response headers to contain array of values

[ioquatix]

A while ago I discussed with @tenderlove - we currently use \n characters to separate multiple headers. e.g.

{"set-cookie" => "foo=x\nbar=y"}

Internally HeaderHash uses an Array I believe, e.g. something like:

{"set-cookie" => ["foo=x", "bar=y"]}

Personally I like this formulation better, it's more efficient for the server implementation and it's easier from the user POV to deal with too. It seems like less of a hack, and it should minimise

So, I vote to deprecate/remove the "\n" representation and prefer the Array representation.

The only limitation is going to be if people start using it everywhere, e.g..

{"content-type" => ["text/html"]}

There are different solutions to this problem: e.g., we could define only certain headers can work like this (notably set-cookie would make sense) or we could mark certain headers as NOT being allowed to be an array (e.g. content-length).

(Epic #1593)

[boazsegev]

I vote to deprecate/remove the "\n" representation and prefer the Array representation.

What an amazing coincidence, I almost posted an issue about this a few weeks ago.

However, after writing it down and adding benchmarks to show why it's faster (by ~40% in simple cases), I realized that servers will have to support both variants (the \n and the Array value) due to backwards compatibility.

In the end, the positive change in the SPECs might not translate to a positive change in practice.

For me (iodine), the \n promises cache locality when parsing the response. However, the fact that the application has to concat strings, which requires memory reallocation and data copying... switching to an Array is much better.

The only limitation is going to be if people start using it everywhere

This will be the same as current use case for \n, which can be used anywhere (including invalid places such as content-length).

I think this part of header "correctness" could be left to common sense.

[ioquatix]

Most headers can be split by comma. The only one which does not follow this rule that I'm aware of is set-cookie. In Protocol::HTTP::Headers this is encoded specifically in the representation. I followed this model from the Mozilla implementation: https://github.com/socketry/protocol-http/blob/master/lib/protocol/http/headers.rb#L159-L161

One way to deal with this is to simply allow set-cookie to be the only array, i.e. if defined it must be an array of zero or more values which get written out as individual headers.

Even thought it's kind of ugly to specify custom behaviour, at least it would make it:

• Easy for servers to do the right thing
• Avoid supporting "\n" in headers where it doesn't make sense (which is every other header AFAIK).
• Predictable user code can just do the right thing, general headers vs set-cookie.
• In terms of compatibility, most code is using Rack::Response or the Utils to add cookies to the response headers anyway. So I don't think this would be a source of major problems.

In fact, considering HTTP headers as general metadata is generally a mistake, in my experience. There are too many things which have specific semantic behaviour which requires specific things to handle.

[boazsegev]

Most headers can be split by comma.

They may, but they don't have to.

Servers (and clients) are both allowed to send the headers in multiple lines rather than comma separated values. i.e. transfer-encoding which may appear more than once and may include chunked, gzip or both.

I don't think Rack should dictate this decision.

There are too many things which have specific semantic behaviour which requires specific things to handle.

Yes, there are, and every day new standards or proposals might pop up.

The wonderful thing about specifying a unified behavior to all HTTP headers, is that the specification isn't fragile - it will still apply to any future change / update.

By allowing developers and servers to make these "mistakes" possible (i.e., multiple content-length headers), we are actually keeping Rack more resilient to changes.

For example, what if multiple content-length headers became a way to indicate multipart messages and their sections (it's easier and safer then writing mime-boundaries)...?

Easy for servers to do the right thing

IMHO, I don't think we need to safe-proof everything. The Rack specification isn't a server or a framework. It doesn't need to require response validation.

Some servers could offer security (at the cost of performance) while testing response validity, others could allow mistakes to pass through.

[ioquatix]

Even puma stuffed this up in the latest release. So, I think we should consider what we do here.

https://twitter.com/nateberkopec/status/1233172403389259782

I don't think Rack should dictate this decision.

Actually, the generic representation of headers is an array of key, value pairs. Rack, by using a hash, is already imposing a data structure which can't represent all possible sets of headers and retain the original order. In order to allow for multiple values, Rack specifies that value strings can contain "\n". But this only really works in the case of set-cookie. If you wanted to implement a proxy, you actually need to correctly handle headers as an array, and correctly deal with hop headers, etc. So, Rack is already making a big assumption about headers, but the implementation is kind of confusing and prone to breakage, as shown by Puma's implementation above.

[boazsegev]

@ioquatix ,

It is clear to me that adding array support could result in an annoying mix between new and old behavior, such as:

{'set-cookie' => [ "cookie1=foo\ncookie2=bar", "cookie3=baz"]}

I believe that your idea is wise, but I also believe it's impractical unless we make breaking changes that prevent the old behavior as a whole.

Even puma stuffed this up in the latest release...

I think the fact that the Puma "patch" was, IMHO, ill considered and may have ignored the Rack specification, does not make the specification "bad", nor does it mean that other servers now need to add support for more variations.

[boazsegev]

P.S.

I understand that Header values are more comfortable to find when stored in a Hash (incoming headers).

However, I wonder if header output should be editable after being set. Does anyone "fix" their headers after setting them?

Changing the Header response to an Array of Arrays might both improve performance and solve this design issue.

I know, it's a backwards compatibility breaking change, but I think breaking backwards compatibility is the only way to update this part of the specification without adding complexity.

🤔

[ioquatix]

Array of Arrays

This is the model I use in protocol-http and it's good.

[jeremyevans]

However, I wonder if header output should be editable after being set. Does anyone "fix" their headers after setting them?

In terms of middleware accessing or modifying response headers, yes, it is very common. For some examples, look at middleware that ships with Rack.

Changing the Header response to an Array of Arrays might both improve performance and solve this design issue.

This turns accessing or modifying response headers from O(1) to O(N) operation. Granted, N in this case is not usually that large.

For the types of operations usually performed on response headers by middleware, using a hash would generally result in simpler code than using an array of arrays. Many middleware assume a hash-like interface for response headers already and would break with a switch to array of arrays.

[boazsegev]

using a hash would generally result in simpler code than using an array of arrays.

I agree with this reasoning 100% - development and maintenance ease is super important. There's so much to do. Keeping developers happy and development time short is a very strong argument.

In terms of middleware accessing or modifying response headers, yes, it is very common. For some examples, look at middleware that ships with Rack.

You're probably right 😅, though I wish you weren't 🙈

Funny enough, I looked at some of these examples when I was designing iodine. I think many of these concerns are server concerns that could (IMHO, should) be shifted to servers. i.e., Content-Length validation, date headers, chunked encoding etc'.

Not that it matters, as it's too often that developers require these additional layers.

[ioquatix]

I’m very strong on the opinion that content-length should not be modified or set by user code. As we saw, it breaks stuff. That’s been my default position in falcon since day one and content-length is ignored by falcon where possible. As well as transfer-encoding, connection, etc, which also should not be set by user. These are protocol level concerns.

All hop headers are ignored: https://github.com/socketry/falcon/blob/master/lib/falcon/adapters/response.rb#L61-L65

			HOP_HEADERS = [
				'connection',
				'keep-alive',
				'public',
				'proxy-authenticate',
				'transfer-encoding',
				'upgrade',
			]

content-length is ignored unless it can't be reliably calculated: https://github.com/socketry/falcon/blob/master/lib/falcon/adapters/output.rb#L34-L53

Falcon will also fail when the content-length and the content don't match up: https://github.com/socketry/protocol-http1/blob/19f55fb5d8bde238e8df7c9f302e86595cdb9ea8/lib/protocol/http1/connection.rb#L304-L306

[boazsegev]

Sorry, I think I got us all sidetracked.

@ioquatix , @jeremyevans , do you agree with my previous assessment that this suggestion only adds complexity (as we will still need to support the existing approach)?

If so, then unless we forgo backwards compatibility, perhaps we could close this issue?

[jeremyevans]

Well, this definitely adds internal complexity. It can make some things simpler for the user, such as supporting multiple values for the same cookie. However, some things could be more complex for the user, since all middleware that needs to operate on header values would need to handle both the string case and the array case. Weighing both sides, I'm against adding allowing response header values to be arrays.

[ioquatix]

I think allowing set-cookie to be an array makes total sense. It's the only header where it makes sense to have multiple values in terms of how Rack implements response headers. If we define only that one header as an array, our internal implementation gets a bit faster and cleaner, and we also ensure that servers are efficient because no other header can contain "\n" and thus we don't need to process every response header expecting that it might contain multiple values.

[jeremyevans]

It may be simpler to make the spec be that only set-cookie can contain "\n", and all other headers cannot contain it. That simplifies response processing in servers to roughly the same degree, and also keeps the spec simpler by using a consistent data type. However, I have not read the RFCs enough to know if only set-cookie can show up multiple times. Unless only set-cookie is allowed to show up multiple times, I think it makes sense to keep the current behavior of allowing it for all headers.

It smells kind of funny to make SPEC different for specific response header keys, but considering we treat some request header names differently in SPEC, it isn't too much of a stretch.

[ioquatix]

I would be okay with that but internally we already use an array so it still seems inefficient.