Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WAT extraction: handle duplicate HTTP response headers #18

Open
cldellow opened this issue Jul 23, 2019 · 1 comment · May be fixed by #38
Open

WAT extraction: handle duplicate HTTP response headers #18

cldellow opened this issue Jul 23, 2019 · 1 comment · May be fixed by #38

Comments

@cldellow
Copy link

See discussion in #16 (comment)

The HTTP protocol permits multiple headers with the same name to be returned in a response:

Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.

This happens commonly, for example the Cache-Control, Vary and Set-Cookie headers are often present more than once.

WAT extracts don't currently capture multiple headers due to

headers.putString(h.getName(),h.getValue());
, which only captures the last header of a given name.

The JSON spec permits an object to have duplicate keys, so the WAT extracts could capture the underlying response more faithfully by overriding JSONObject.encode on MetaData to handle this scenario.

This change will be invisible to users using JSON parsers that bind to an object (JavaScript's JSON.parse('{"a": "a", "a": "b"}') => {"a": "b"}, e.g.). If an end-user wants to access the entire set of headers, they'll likely have to use a slightly less user-friendly interface to their JSON library.

@sebastian-nagel
Copy link

After a closer look: allowing repeated keys/names in MetaData would require to change the underlying JSON implementation. That's maybe even not worth to explore, given that it would hardly make it into the upstream code, cf. iipc#84.

Opened iipc#98 for a solution which would break with backward-compatibility because the values of repeated headers are stored as a JSONArray.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants