mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anand Mazumdar (JIRA)" <>
Subject [jira] [Commented] (MESOS-3601) Formalize all headers and metadata for HTTP API Event Stream
Date Tue, 17 Jan 2017 17:26:26 GMT


Anand Mazumdar commented on MESOS-3601:

The implementation of the headers proposed in the design doc is being tracked on MESOS-6936

Resolving this for now. 

> Formalize all headers and metadata for HTTP API Event Stream
> ------------------------------------------------------------
>                 Key: MESOS-3601
>                 URL:
>             Project: Mesos
>          Issue Type: Improvement
>    Affects Versions: 0.24.0
>         Environment: Mesos 0.24.0
>            Reporter: Ben Whitehead
>            Assignee: Anand Mazumdar
>            Priority: Blocker
>              Labels: api, http, mesosphere, wireprotocol
>             Fix For: 1.2.0
> 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|].

This message was sent by Atlassian JIRA

View raw message