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