Ben Whitehead created MESOS-3601:
------------------------------------
Summary: 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
>From and 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)
