You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Qian Zhang (JIRA)" <ji...@apache.org> on 2015/10/13 16:35:05 UTC
[jira] [Updated] (MESOS-3601) Formalize all headers and metadata
for HTTP API Event Stream
[ https://issues.apache.org/jira/browse/MESOS-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Qian Zhang updated MESOS-3601:
------------------------------
Description:
>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].
was:
>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].
> 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, 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)