[jira] [Updated] (MESOS-3601) Formalize all headers and metadata for HTTP API Event Stream

["James DeFelice (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MESOS-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James DeFelice updated MESOS-3601:
----------------------------------
    Labels: api http mesosphere wireprotocol  (was: api http wireprotocol)

> Formalize all headers and metadata for HTTP API Event Stream
> ------------------------------------------------------------
>
>                 Key: MESOS-3601
>                 URL: https://issues.apache.org/jira/browse/MESOS-3601
>             Project: Mesos
>          Issue Type: Improvement
>    Affects Versions: 0.24.0
>         Environment: Mesos 0.24.0
>            Reporter: Ben Whitehead
>              Labels: api, http, mesosphere, wireprotocol
>
> From an HTTP standpoint the current set of headers returned when connecting to the HTTP scheduler API are insufficient. 
> {code:title=current headers}
> HTTP/1.1 200 OK
> Transfer-Encoding: chunked
> Date: Wed, 30 Sep 2015 21:07:16 GMT
> Content-Type: application/json
> {code}
> Since the response from mesos is intended to function as a stream {{Connection: keep-alive}} should be specified so that the connection can remain open.
> If RecordIO is going to be applied to the messages, the headers should include the information necessary for a client to be able to detect RecordIO and setup it response handlers appropriately.
> How RecordIO is expressed will come down to the semantics of what is actually "Returned" as the response from {{POST /api/v1/scheduler}}.
> h4. Proposal
> One approach would be to leverage http as much as possible, having a client specify an {{Accept-Encoding}} along with the {{Accept}} header to indicate that it can handle RecordIO {{Content-Encoding}} of {{Content-Type}} messages.  (This approach allows for things like gzip to be woven in fairly easily in the future)
> For this approach I would expect the following:
> {code:title=Request}
> POST /api/v1/scheduler HTTP/1.1
> Host: localhost:5050
> Accept: application/x-protobuf
> Accept-Encoding: recordio
> Content-Type: application/x-protobuf
> Content-Length: 35
> User-Agent: RxNetty Client
> {code}
> {code:title=Response}
> HTTP/1.1 200 OK
> Connection: keep-alive
> Transfer-Encoding: chunked
> Content-Type: application/x-protobuf
> Content-Encoding: recordio
> Cache-Control: no-transform
> {code}
> When Content-Encoding is used it is recommended to set {{Cache-Control: no-transform}} to signal to any proxies that no transformation should be applied to the the content encoding [Section 14.11 RFC 2616|http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.11].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)