Repository navigation
Clarify header grouping #47
Description
The spec currently declares:
Header values are assumed to be in a mixed format, meaning that a normally comma separated header may appear as a single entry in the values array, one entry per value, or a mixture of the two. (e.g. new string[1] {"value, value, value"}, new string[3] {"value", "value", "value"}, or new string[2] {"value, value", "value"})
However, as @kolektiv pointed out, that's not entirely clear. My best recollection is that OWIN would not change the header values, just pull all headers with the same header name into a single array, and the framework would then need to process the header values as received by the server.
I propose we amend to the following:
Header values are assumed to be in a mixed format, meaning that a normally comma separated header may appear as a single entry in the values array, one entry per value, or a mixture of the two (e.g. new string[1] {"value, value, value"}, new string[3] {"value", "value", "value"}, or new string[2] {"value, value", "value"}). Servers conforming to OWIN SHOULD NOT change the header values received in the HTTP request and SHOULD expose the header values as received.
I'm happy to change the above from SHOULD to MUST.
Activity
serialseb commentedon Oct 31, 2015
This is what i have in 1.0.1:
EddieGarmon commentedon Nov 1, 2015
The more we accommodate people doing the wrong thing in the first place, the harder it is to do things right.
panesofglass commentedon Nov 2, 2015
@EddieGarmon, I agree. @serialseb, I like what you have. I would lean towards wanting "MUST NOT," but I'm sure some server implementations already violate that condition, though I could be wrong.
Tratcher commentedon Nov 2, 2015
Http.sys/IIS violates these guidelines for 'known' request headers. It's annoying sometimes. @EddieGarmon I agree in principal, but unfortunately most apps don't control their end-to-end stack and need to work around deficiencies in 3rd party components.
EddieGarmon commentedon Nov 2, 2015
@Tratcher A specification is not an application.
Either fully allow/support header modification/normalization or don't. Being on the fence in a spec leads to abuse and true non-adoption.
Did HTTP/2 bend just because if a poor IIS implementation? I don't think so.
serialseb commentedon Nov 4, 2015
Do remember that we can't enforce additional restrictions on top of owin 1.0 (or any 1.x) as a SHOULD becoming a MUST would invalidate existing implementations that were valid before. 1.0.1 is supposed to clarify 1.0.0, not redefine it.
The way to address these is either to postpone a better definition for a 2.0 (aka the ship has sailed), or work on a "Designed for OWIN" certification that has additional requirements (such as scoring on SHOULD and MUST and CAN and COULD and only providing the certification to 90% score or what not)
Also, please note i'm waiting for comments on the other issues reported on the middleware spec brefore starting an RC vote, after whcih we can spend much time finalising 1.0.1.
panesofglass commentedon Nov 12, 2015
Comments added elsewhere (at last). :)