[
https://issues.apache.org/jira/browse/THRIFT-5882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17985718#comment-17985718
]
Yuxuan Wang commented on THRIFT-5882:
-------------------------------------
So, THeaderTransport itself is built on top of TBinaryProtocol,
TCompactProtocol, TFramedTransport, and TZlibTransport. If the other end of the
connection is actually not using THeaderTransport but TBinaryProtocol with
TSocket, or TCompactProtocol with TFramendTransport, that can be auto detected
(but no headers can be sent that way). If both ends are using THeaderTransport,
then it's always framed, and there's something in the header to tell the other
end whether TBinaryProtocol or TCompactProtocol shall be used, and whether
TZlibTransport should be applied.
If you look at any implementation of THeaderProtocol, there's almost nothing
special there, besides that it requires the transport to be THeaderTransport,
then it just delegates to the TBinaryProtocol or TCompactProtocol in the
THeaderTransport to handle the TProtocol things. Most of the heavylifting is
inside THeaderTransport implementation, which is why we also have it exposed
with its APIs.
The reason you found using the "binary" protocol over the "header" transport
working is likely just because by default THeaderTransport uses TBinaryProtocol
under the hood (if you want to use TCompactProtocol instead that need to be
specified explicitly). The issue you saw on the server is probably a bug in
cpp's THeader implementation.
As for THRIFT-5883, the part that having the client being
TBufferedTransport+TBinaryProtocol works is because that's backward
compatibility feature from server's THeaderTransport/Protocol implementation
(there's nothing special about TBufferedTransport on the wire level, the buffer
is just a local implementation detail)
> [c++] Is using the "header" transport supported ?
> -------------------------------------------------
>
> Key: THRIFT-5882
> URL: https://issues.apache.org/jira/browse/THRIFT-5882
> Project: Thrift
> Issue Type: Question
> Components: C++ - Library
> Affects Versions: 0.22.0
> Reporter: Jean-Charles Quillet
> Priority: Major
>
> In the TestServer.cpp and TestClient.cpp I can see that it is not possible to
> choose the "header" transport, one can only choose the "header" protocol.
> Then I'm wondering, is using the "header" transport a supported use case?
> For the context, I work on a cpp server that use the "buffered" transport
> over the "binary" protocol. I need it to be able to answer to clients using
> the same stack for backward compatibility as well as client which sends
> headers along requests (transport and protocol to be defined accordingly).
> I was thinking about moving the transport of the server from "buffered to
> "header". But I could not find evidence that it is a supported use case
> looking at the documentation and the test.
> See also [THRIFT-5883|https://issues.apache.org/jira/browse/THRIFT-5883]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
