[
https://issues.apache.org/jira/browse/THRIFT-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16275418#comment-16275418
]
Chet Murthy commented on THRIFT-3877:
-------------------------------------
I dug into the go-cpp (go server, cpp client) problem.
TL;DR this is a basic limitation of the Golang HTTP stack, which is ....
designed with no flexibility in mind. None whatsoever. To allow what Thrift
"oneway" needs, we need to write our own HTTP stack.
(0) reminder: the semantics of "oneway" is that literally no response is sent.
Not a single byte. This is .... well, an interesting perversion of the HTTP
protocol, and we might discuss whether we want to undo it. But let's assume
for this discussion that we want to keep things this way .....
(1) in golang, the http stack "comes with" the language. And for instance in
golang 1.8, in go/src/net/http/server.go, we learn that the HTTP server stack
is configured with a set of "handler functions", for various paths. A handler
function is invoked this:
type HandlerFunc func(ResponseWriter, *Request)
So y'know, it's got a place to which it can write its response.
If it doesn't write a response, that is the same as a zero-byte response. So
upon return from the method (e.g. "TestOneway"), the HTTP server stack will put
out its response, with a zero-byte body. But it puts out a response.
(2) There are two solutions:
(a) write our own HTTP stack. This isn't so hard, eh?
(b) But I think that the right approach, is to change the semantics of "oneway
HTTP" so that a response is always returned. Then via HTTP request pipelining,
we get the same client-visible behaviour as today. Though, the spec says that
clients SHOULD NOT pipeline non-idempotent requests (and all POSTs are assumed
non-idempotent). But this is a quibble, and in any case, it's a "SHOULD NOT".
Why do I think that the right thing is for the HTTP transports to (all) switch
to (silently) returning a response for a oneway method? B/c otherwise, the
HTTP transport isn't very useful. Anyplace where there are HTTP proxies (and
for instance, there are transparent network proxies in the wild, right?) you'll
break them. Also, if Thrift-HTTP conformed to the HTTP spec, it might be worth
looking into building a Thrift plugin for the Apache webserver. It would widen
the utility of Thrift, I think.
And the work isn't all that significant.
(3) I feel like it's worth noting that Thrift's use of HTTP (for oneway) really
isn't "conforming". In the spec, the assumption that every request will
receive a response is .... a pervasive unstated assumption. I doubt any HTTP
standards-person would say it's even remotely conforming.
> C++: library don't work with HTTP (csharp server, cpp client; need cross test
> enhancement)
> ------------------------------------------------------------------------------------------
>
> Key: THRIFT-3877
> URL: https://issues.apache.org/jira/browse/THRIFT-3877
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
> Affects Versions: 0.9.3, 0.10.0
> Environment: Windows 7, Visual Studio 2013 (C#), Qt 5.7 (MSVC 12).
> Thrift from git repo, SHA-1: 5a3f855b4e6882184f13c698855c877241144a12 (master)
> Reporter: Sergey Fasman
> Assignee: James E. King, III
> Priority: Critical
>
> Client on C++.
> Tested on C# HTTP server and client — work ideal.
> Then create client on C++. Client after request starts infinitly wait for
> data.
> For example, JSON protocol read data symbol by symbol, when trying read: it
> always try to call recv function (even all data already received).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
