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

Reply via email to