aurora-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zameer Manji <zma...@apache.org>
Subject Re: Review Request 50685: Support TBinaryProtocol over HTTP
Date Wed, 03 Aug 2016 19:28:07 GMT


> On Aug. 2, 2016, 6:58 p.m., Joshua Cohen wrote:
> > So, on further reflection, it doesn't necessarily make sense for the response type
to be dictated by the `Content-Type` of the request. We should probably use the `Accept` header
instead? I don't necessarily know if the use case exists to send json yet want to receive
binary, but it's more idiomatic HTTP to support that possibility.
> 
> Stephan Erb wrote:
>     +1 for the accept header

I tried and wasn't able to make progress. The problem is that the Accept header format is
complex: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html and jetty doesn't give us
an Accept header parser. Manually parsing or adding another dependency seems fragile and something
I would like to avoid.

I believe my current patch is robust as is, although it is not idiomatic. It doesn't preclude
us from being more idiomatic later in the future as well.


- Zameer


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/50685/#review144577
-----------------------------------------------------------


On Aug. 2, 2016, 5:10 p.m., Zameer Manji wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50685/
> -----------------------------------------------------------
> 
> (Updated Aug. 2, 2016, 5:10 p.m.)
> 
> 
> Review request for Aurora, Joshua Cohen, Maxim Khutornenko, and Dmitriy Shirchenko.
> 
> 
> Bugs: AURORA-1743
>     https://issues.apache.org/jira/browse/AURORA-1743
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> This replaces the `TServlet` servlet from thrift with our own servlet which dispatches
thrift responses based on the content type of the request. This enables a client to use either
the thrift json protocol or the binary protocol when communicating with the scheduler.
> 
> Without this patch the current behaviour is:
> - Regardless of content type of the request, assume the request is json and return json
with a `application/x-thrift` content type.
> 
> With this patch the behaviour becomes:
> - A request with no content type is assumed to be json and returns json with a `application/vnd.apache.thrift.json`
content type. This maintains backwards compatability with clients that may not set a content
type.
> - A request with a content type of `application/x-thrift` is assumed to be json and returns
json with a `application/vnd.apache.thrift.json` content type.  This maintains backwards compatability
with the client.
> - A request with a content type of `application/json` returns json with a `application/vnd.apache.thrift.json`
content type. This maintains backwards compatability with the AJAX UI.
> - A request with a content type of `application/vnd.apache.thrift.json` returns json
with a `application/vnd.apache.thrift.json` content type.
> - A request with a content type of `application/vnd.apache.thrift.binary` returns binary
thrift with a `application/vnd.apache.thrift.json` content type.
> - Any other content type in a request results in a HTTP 415 response.
> 
> 
> Diffs
> -----
> 
>   RELEASE-NOTES.md d46420ef876b88d9ab68c4816f1c2d6780aba702 
>   src/main/java/org/apache/aurora/scheduler/http/api/ApiModule.java cd5adf9655dc3368dbe06bfee15c65182176be2e

>   src/main/java/org/apache/aurora/scheduler/http/api/TContentAwareServlet.java PRE-CREATION

>   src/test/java/org/apache/aurora/scheduler/http/api/ApiIT.java 31f5cb3bed48eef60c3b2becb2ed285e93f2bd5a

>   src/test/java/org/apache/aurora/scheduler/http/api/TContentAwareServletTest.java PRE-CREATION

> 
> Diff: https://reviews.apache.org/r/50685/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Zameer Manji
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message