[ 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)