> On Sep 7, 2016, at 8:48 PM, James Peach <jpe...@apache.org> wrote: > > >> On Sep 7, 2016, at 8:30 PM, Sudheer Vinukonda >> <sudheervinuko...@yahoo.com.INVALID> wrote: >> >> I was replying to this - >> >>> "I don’t think this is any different from allowing SPDY or HTTP/2 to mark >>> their transactions as non-internal." >> >> Marking Spdy/H2 as non-internal works because of the special handling done >> via FetchSM. With the proposed new API, you are intending to mark plugin >> generated requests as non-internal. My point is that it'd likely cause >> issues. I'll try to find some time to dig and provide specifics. > > That would be great, because I’m struggling to see the special case here :)
Below are a couple of recent related jiras, there's likely more. TS-3404 TS-3777 > >> >> >>> On Sep 7, 2016, at 7:38 PM, James Peach <jpe...@apache.org> wrote: >>> >>> >>>> On Sep 7, 2016, at 6:39 PM, Sudheer Vinukonda >>>> <sudheervinuko...@yahoo.com.INVALID> wrote: >>>> >>>> Spdy/H2 are different - they also have a stream flag set which is handled >>>> differently in FetchSM. >>> >>> This proposal doesn’t touch FetchSM, since the TSFetchUrl API is not >>> extensible in any meaningful way (I’d argue it is totally broken). Are you >>> referring to the TS_FETCH_FLAGS_STREAM flag? That doesn’t apply here >>> because there’s no API change for TSFetchUrl. >>> >>>> >>>>> On Sep 7, 2016, at 6:27 PM, James Peach <jpe...@apache.org> wrote: >>>>> >>>>> >>>>>> 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 >
