I approved the PR, but just to conclude the discussion here, I was convinced that having "Txn" in the function name makes sense. The return value for transactions that receive CONNECT method could be differentiated (e.g. TS_TXN_TYPE_CONNECT_TUNNEL), but I don't have a strong opinion here. It's easy to determine whether CONNECT is used by using other functions.
Masakazu On Fri, Sep 22, 2023 at 4:53 PM SUSAN HINRICHS <shinr...@ieee.org.invalid> wrote: > And Connect always confuses me. Let me test that scenario. > > On Fri, Sep 22, 2023, 4:24 PM Masakazu Kitajo <m4s...@gmail.com> wrote: > > > Hmm, I probably don't completely understand tunneling on ATS, especially > > the tr-* stuff, but ok. I don't think we should copy information. > > > > Another question. Is this also related to CONNECT method? If so, the > > transaction that received CONNECT method returns TRUE when > TSHttpTxnTypeGet > > is called? Does it also apply to CONNECT on HTTP/2? On H2, CONNECT method > > creates a tunnel on a stream but not a connection. If the API works for > > this situation, "Txn" may actually make sense. > > > > On Thu, Sep 21, 2023 at 5:10 PM SUSAN HINRICHS <shinr...@ieee.org.invalid > > > > wrote: > > > > > 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 > > > >> > > > > >> > > > > > > > > > >
