When the web server for the v5 kraken api sends a reply, if the reply is too long it uses chunk encoding that looks like this.
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Server: nginx
< Access-Control-Allow-Origin: *
< Twitch-Trace-Id: 78f6fb762ccb2f80d18442c3375ea688
< X-Ctxlog-Logid: 1-5cbe1b2d-9de20388bb7052d80b8853c8
< Front-End-Https: on
< Timing-Allow-Origin: https://www.twitch.tv
< Date: Mon, 22 Apr 2019 19:51:09 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Connection: Transfer-Encoding
Notice the Connection header appears twice, and there is an extra whitespace before " chunked" (the forum markup deletes it, so you cannot see it here), this breaks some HTTP clients.
RFC2616 section 4.2:
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.
Nothing is wrong this is correct.
HTTP 1.1 allows multiple Connection headers. The semantics of multiple such headers are defined to be the same as a single header with all values joined together with commas, e.g.
is the same as:
According with paragraph 4.2 of RFC2616 (HTTP/1.1), field values might be preceded by whitespace, but not the field name:
If you are having an issue, it’s YOUR HTTP client making the request, not Twitch.
Oh jeez were living in 1999
Actually the up to date RFC is rfc7230, rfc2616 is obsolete.
Which states that:
A sender must not generate multiple header fields with the same field name in a message unless either the entire field value for that header field is defined as a comma-separated list [i.e., #(values)] or the header field is a well-known exception (as noted below).
The exception is the Set-Cookie header.
The multiple whitespace instead of single seperating " chunked" from the field name, is indeed allow but holy crap, in all my years this is the first time I see a “professional” webserver return it like that. Professional defined as the webserver for a company valued at over 1b dollars.
Indeed I have patched my HTTP client, but just bringing this to the attention of Twitch, as I am sure a crapton of other clients will give issues.
If we want to start nit-picking the RFC (7230),
Connection header follows
Connection = 1#connection-option, which means it’s a comma-separated list and fits the exception in your quoted part.
As far as the extra space in the transfer-encoding header goes, it is weird and inconsistent. It does go against the preference set in the RFC, but it is allowed in the RFC. Should it, in a perfect world, be fixed for consistency? Yes. Is it ever going to be the highest priority item on the todo list? No, if v5 is going to go away as planned.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.