> On Sep 7, 2016, at 5:48 PM, Sudheer Vinukonda > <sudheervinuko...@yahoo.com.INVALID> wrote: > > Can you describe the real purpose of allowing to change if a transaction is > external/internal - for example, is it merely for recording/metrics or is it > for a more significant functional purpose?
It is both. If a request is logically from a client then the @internal remap.config filter should deny, the stale_while_revalidate plugin should not ignore it, and it should be generally treated as if the protocol plugin did not intermediate. “internal” carries the string connotation that this is a trusted or special transaction, which is not true for protocol plugins. > > Atleast, in the current implementation, allowing arbitrary control of the > internal state of a txn sounds dangerous to me - I recall some funky handling > of some headers (Connection/Keep Alive) and some special handling for POST > method etc. This API may expose problems from that code. I don’t think this is any different from allowing SPDY or HTTP/2 to mark their transactions as non-internal. > > Thanks, > > Sudheer > >> On Sep 7, 2016, at 5:24 PM, James Peach <jpe...@apache.org> wrote: >> >> Hi all, >> >> It is common to write protocol plugins that accept a non-HTTP protocol and >> generate HTTP request using TSHttpConnectWithPluginId(). In this case, >> although the HTTP transaction is technically an internal transaction, it is >> logically external since it is generated directly on behalf of clients. To >> address this, I'd like to propose an API to allow plugins to toggle whether >> a transaction is considered internal or not. >> >> tsapi void TSVConnInternalSet(TSVConn connp, int internal); >> >> The sample usage is straightforward: >> >> TSVConn vc = TSHttpConnectWithPluginId(addr, "plugin-name", 0); >> TSVConnInternalSet(vc, false); >> >> The corresponding implementation is >> https://github.com/apache/trafficserver/pull/986 and the Jira ticket is >> https://issues.apache.org/jira/browse/TS-4825. I'll add a manual page before >> committing. >> >> thanks, >> James >
