I looked at this a bit more, and it really is functionally an attribute of the transaction. The transaction is either a HTTP request or a tunnel. And if it is a tunnel it can be a tunnel because of a config or API call. Or it can be a tunnel due to a parse error (if tr-pass is enabled).
We could copy this information back to the enclosing vconn or session object, but extra copies of data just means they will get out of sync one day. On Tue, Sep 19, 2023 at 3:11 PM SUSAN HINRICHS <shinr...@ieee.org> wrote: > Sorry, I missed this in my clogged inbox. > > It is a characteristic of the vconn. Either the vconn is tunneled (based > on parse failure or configuration) or all the transactions will be HTTP. > > However from an implementation perspective this is information we pull > from the HttpSM. Let me think a bit on how invasive it would be to add > this information to the vconn. Then I could pull the vconn from the txn > object to make this call. > > On Wed, Sep 13, 2023 at 12:19 PM Masakazu Kitajo <mas...@apache.org> > wrote: > >> Is it possible that the types of transactions on a connection are >> different? I suppose it's a type of connection or session. >> >> - Masakazu >> >> On Mon, Sep 11, 2023 at 5:22 PM SUSAN HINRICHS <shinr...@ieee.org.invalid >> > >> wrote: >> >> > I propose adding a new hook TS_HTTP_TUNNEL_START_HOOK. It triggers when >> a >> > blind tunnel starts. A plugin using this hook has the opportunity to use >> > some other information (e.g., policy, time of day, cat entrails) to >> > determine whether the blind tunnel should be allowed. >> > >> > I also propose a new API >> > TSTxnType TSHttpTxnTypeGet(TSHttpTxn txnp) >> > >> > It returns an enumerated value based on the type of the translation. >> One of >> > TS_TXN_TYPE_HTTP, TS_TXN_TYPE_EXPLICIT_TUNNEL, >> TS_TXN_TYPE_TR_PASS_TUNNEL. >> > A plugin can use this information in the Start Hook to make decisions >> about >> > whether to allow the tunnel. >> > >> > PR https://github.com/apache/trafficserver/pull/10308 >> > >> >
