rymsha
commented
3 years ago New behavior after #8521 is that duplicate header from different parts won't generate an error. Instead response will have only one header value for each key (last one wins)
HTTP Header specs went through a few RFCs and still problematic to implement correctly. Generally, "duplicate header key" is exotic:
- It may be used for Accept* headers but those are mostly client ones.
- Well known exception Set-Cookie https://tools.ietf.org/html/rfc6265#section-3 But we support cookies natively via cookies response object.
- It may be used for Link header, but Link header specification always workarounds it with
,separated values. We may soon support Links natively #8197 - Other headers that need multiple values have an official workaround to "combine" them. https://tools.ietf.org/html/rfc7230#section-3.2.2
Current implementation of Enonic XP Web Response is written so that keys are unique (it is a js/json object), changing it in a non-breaking way would be too much effort for an exotic use-case. If there is a demand for this, we can open a new feature request.
A user reported that when they have a part sending in a header that is allready present it crashes.
A part returns with a header. The part is added twice on the same site. This creates com.enonic.xp.web.WebException: Multiple entries with same key:”
The system merges: pageContributions and cookies, but not headers?