You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Ben Whitehead (JIRA)" <ji...@apache.org> on 2015/10/07 20:38:26 UTC

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

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)