{"action":"reopened","issue":{"url":"https://api.github.com/repos/k3po/k3po/issues/136","repository_url":"https://api.github.com/repos/k3po/k3po","labels_url":"https://api.github.com/repos/k3po/k3po/issues/136/labels{/name}","comments_url":"https://api.github.com/repos/k3po/k3po/issues/136/comments","events_url":"https://api.github.com/repos/k3po/k3po/issues/136/events","html_url":"https://github.com/k3po/k3po/issues/136","id":58129806,"number":136,"title":"Http Sematics to support chunked encoding extensions and trailer","user":{"login":"dpwspoon","id":2014623,"avatar_url":"https://avatars.githubusercontent.com/u/2014623?v=3","gravatar_id":"","url":"https://api.github.com/users/dpwspoon","html_url":"https://github.com/dpwspoon","followers_url":"https://api.github.com/users/dpwspoon/followers","following_url":"https://api.github.com/users/dpwspoon/following{/other_user}","gists_url":"https://api.github.com/users/dpwspoon/gists{/gist_id}","starred_url":"https://api.github.com/users/dpwspoon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dpwspoon/subscriptions","organizations_url":"https://api.github.com/users/dpwspoon/orgs","repos_url":"https://api.github.com/users/dpwspoon/repos","events_url":"https://api.github.com/users/dpwspoon/events{/privacy}","received_events_url":"https://api.github.com/users/dpwspoon/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/k3po/k3po/labels/enhancement","name":"enhancement","color":"84b6eb"},{"url":"https://api.github.com/repos/k3po/k3po/labels/k3po-core","name":"k3po-core","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-02-18T21:20:49Z","updated_at":"2016-02-03T21:17:58Z","closed_at":null,"body":"As per [spec](https://tools.ietf.org/html/rfc7230#section-4.1), transfer encoding chunk can have extensions and a trailer.  As of now there is no way to set that in http scripts.\r\n\r\n>\r\n>4.1.  Chunked Transfer Coding\r\n>\r\n>   The chunked transfer coding wraps the payload body in order to\r\n>   transfer it as a series of chunks, each with its own size indicator,\r\n>   followed by an OPTIONAL trailer containing header fields.  Chunked\r\n>   enables content streams of unknown size to be transferred as a\r\n>   sequence of length-delimited buffers, which enables the sender to\r\n>   retain connection persistence and the recipient to know when it has\r\n>   received the entire message.\r\n>\r\n>     chunked-body   = *chunk\r\n>                      last-chunk\r\n>                      trailer-part\r\n>                      CRLF\r\n>\r\n>     chunk          = chunk-size [ chunk-ext ] CRLF\r\n>                      chunk-data CRLF\r\n>     chunk-size     = 1*HEXDIG\r\n>     last-chunk     = 1*(\"0\") [ chunk-ext ] CRLF\r\n>\r\n>     chunk-data     = 1*OCTET ; a sequence of chunk-size octets\r\n>\r\n>   The chunk-size field is a string of hex digits indicating the size of\r\n>   the chunk-data in octets.  The chunked transfer coding is complete\r\n>   when a chunk with a chunk-size of zero is received, possibly followed\r\n>   by a trailer, and finally terminated by an empty line.\r\n>\r\n>   A recipient MUST be able to parse and decode the chunked transfer\r\n>   coding.\r\n>\r\n>4.1.1.  Chunk Extensions\r\n>\r\n>   The chunked encoding allows each chunk to include zero or more chunk\r\n>   extensions, immediately following the chunk-size, for the sake of\r\n>   supplying per-chunk metadata (such as a signature or hash),\r\n>   mid-message control information, or randomization of message body\r\n>   size.\r\n>\r\n>     chunk-ext      = *( \";\" chunk-ext-name [ \"=\" chunk-ext-val ] )\r\n>\r\n>     chunk-ext-name = token\r\n>     chunk-ext-val  = token / quoted-string\r\n>\r\n>   The chunked encoding is specific to each connection and is likely to\r\n>   be removed or recoded by each recipient (including intermediaries)\r\n>   before any higher-level application would have a chance to inspect\r\n>   the extensions.  Hence, use of chunk extensions is generally limited\r\n>\r\n>\r\n>\r\n>\r\n>Fielding & Reschke           Standards Track                   [Page 36]\r\n> \r\n>RFC 7230           HTTP/1.1 Message Syntax and Routing         June 2014\r\n>\r\n>\r\n>   to specialized HTTP services such as \"long polling\" (where client and\r\n>   server can have shared expectations regarding the use of chunk\r\n>   extensions) or for padding within an end-to-end secured connection.\r\n>\r\n>   A recipient MUST ignore unrecognized chunk extensions.  A server\r\n>   ought to limit the total length of chunk extensions received in a\r\n>   request to an amount reasonable for the services provided, in the\r\n>   same way that it applies length limitations and timeouts for other\r\n>   parts of a message, and generate an appropriate 4xx (Client Error)\r\n>   response if that amount is exceeded.\r\n>\r\n>4.1.2.  Chunked Trailer Part\r\n>\r\n>   A trailer allows the sender to include additional fields at the end\r\n>   of a chunked message in order to supply metadata that might be\r\n>   dynamically generated while the message body is sent, such as a\r\n>   message integrity check, digital signature, or post-processing\r\n>   status.  The trailer fields are identical to header fields, except\r\n>   they are sent in a chunked trailer instead of the message's header\r\n>   section.\r\n>\r\n>     trailer-part   = *( header-field CRLF )\r\n>\r\n>   A sender MUST NOT generate a trailer that contains a field necessary\r\n>   for message framing (e.g., Transfer-Encoding and Content-Length),\r\n>   routing (e.g., Host), request modifiers (e.g., controls and\r\n>   conditionals in Section 5 of [RFC7231]), authentication (e.g., see\r\n>   [RFC7235] and [RFC6265]), response control data (e.g., see Section\r\n>   7.1 of [RFC7231]), or determining how to process the payload (e.g.,\r\n>   Content-Encoding, Content-Type, Content-Range, and Trailer).\r\n>\r\n>   When a chunked message containing a non-empty trailer is received,\r\n>   the recipient MAY process the fields (aside from those forbidden\r\n>   above) as if they were appended to the message's header section.  A\r\n>   recipient MUST ignore (or consider as an error) any fields that are\r\n>   forbidden to be sent in a trailer, since processing them as if they\r\n>   were present in the header section might bypass external security\r\n>   filters.\r\n>\r\n>   Unless the request includes a TE header field indicating \"trailers\"\r\n>   is acceptable, as described in Section 4.3, a server SHOULD NOT\r\n>   generate trailer fields that it believes are necessary for the user\r\n>   agent to receive.  Without a TE containing \"trailers\", the server\r\n>   ought to assume that the trailer fields might be silently discarded\r\n>   along the path to the user agent.  This requirement allows\r\n>   intermediaries to forward a de-chunked message to an HTTP/1.0\r\n>   recipient without buffering the entire response."}}